Author Topic: Suggestions for 3.9  (Read 85446 times)

Ian @ un4seen

  • Administrator
  • Posts: 20210
Re: Suggestions for 3.9
« Reply #350 on: 10 Aug '17 - 17:28 »
I'm using an ultra high resolution monitor and the default skin is nearly unreadable, but the 'hours' is shown - the skin I'm using I got from someone on another forum and it appears that when the "font_listsize" and "font_listnumsize" is set above about 48-52 points it cuts the 'hours' off. When I drag and drop a track that's over an hour into the playlist it cuts off the 'hours'  and that's true whether for not the 'type' column is active or not. But, switching skins back and forth or restarting xmplay it displays correctly.Also this is with the playlist panel and not when the playlist is incorporated into the main panel- I hope that makes sense.

Please upload that skin to have a look at here:

   ftp.un4seen.com/incoming/

Can the 'Total time/count display' be given it's own setting in 'skinconfig.txt' maybe a new parameter 'font_listtimesize' can be created so that the size can be set independently - right now it uses the 'font_listnumsize' which is also used as the playlist track number/time.

Yes, I think that can be arranged.

I haven't noticed that before, but apparently there's a need for correction on how XMPlay's maximum text width works:



Here, I set it to 24 characters and used absurdly long path with a long album title. As can be seen the text is broken between letter characters but as Japanese language doesn't use spaces the line is not broken as supposed. Or maybe that's because of squareness of the characters.

P.S. In case you wonder, Japanese sentence can be split mid-word, that's normal.

XMPlay currently splits lines at spaces. I suppose XMPlay would need to detect when Japanese characters are used, and perhaps others too? Do you know what Unicode blocks it should look for?

P.P.S. Apparently there's an issue with splitting file path when XMPlay is running under Japanese system and ¥ character is used instead of \

Can either character be used, ie. could XMPlay simply replace all '¥' in filenames with '\'? For reference, please upload your XMPLAY.PLS file to have a look at here:

   ftp.un4seen.com/incoming/

mortstev

  • Posts: 7
Re: Suggestions for 3.9
« Reply #351 on: 11 Aug '17 - 21:44 »
Please upload that skin to have a look at here:
   ftp.un4seen.com/incoming/

It's there - at least I hope it is, when I do an 'ls -l' it doesn't appear in the listing, but I uploaded it and did get "Transfer complete".

The file names are:
albumart.xmpskin
and
albumart-bigger.xmpskin

You can also make those available in the 'skins' section for everyone to download if you'd like.

Thanks for you help!

Mort
--

tails__

  • Posts: 6
Re: Suggestions for 3.9
« Reply #352 on: 14 Aug '17 - 00:18 »
Quote
Can either character be used, ie. could XMPlay simply replace all '¥' in filenames with '\'? For reference, please upload your XMPLAY.PLS file to have a look at here:

I've uploaded the playlist to FTP. As far as I can see, it's just the font having backslash symbol replaced with half-width yen character for compatibility reasons.


Now, about unicode blocks. Main CJK stuff can be found in this range:



And second Chinese block is there:



Then, there is U+FF00–FFEF range which defines full-width ASCII variant with half-width katakana (second Japanese syllabary) which begins at U+FF66 and ends at U+FF9F:



Characters U+FF9E and U+FF9F have to be stacked together with character they came after though.
« Last Edit: 14 Aug '17 - 00:22 by tails__ »

Ian @ un4seen

  • Administrator
  • Posts: 20210
Re: Suggestions for 3.9
« Reply #353 on: 14 Aug '17 - 18:17 »
It's there - at least I hope it is, when I do an 'ls -l' it doesn't appear in the listing, but I uploaded it and did get "Transfer complete".

The file names are:
albumart.xmpskin
and
albumart-bigger.xmpskin

The skins were received, thanks. I don't seem to be able to reproduce the problem though. Do I need to make some changes to the skin's skinconfig.txt file? If so, please give those too.

I've uploaded the playlist to FTP. As far as I can see, it's just the font having backslash symbol replaced with half-width yen character for compatibility reasons.

Oh, is it just the font that is making the backslashes look like something else? If so, I'm not sure what can be done about that. Do you see it happen with all fonts? If so, I guess it affects other software too?

Now, about unicode blocks. Main CJK stuff can be found in this range:



And second Chinese block is there:



Then, there is U+FF00–FFEF range which defines full-width ASCII variant with half-width katakana (second Japanese syllabary) which begins at U+FF66 and ends at U+FF9F:



Characters U+FF9E and U+FF9F have to be stacked together with character they came after though.

Does that mean everything between 3190-A48F and 20000-2FA1F can be split anywhere?

tails__

  • Posts: 6
Re: Suggestions for 3.9
« Reply #354 on: 14 Aug '17 - 18:42 »
Quote
Oh, is it just the font that is making the backslashes look like something else? If so, I'm not sure what can be done about that. Do you see it happen with all fonts? If so, I guess it affects other software too?

Yes, actually, with Korean fonts backslash is replaced with something like W, so this is just font issue. Still, cutting text at "\" character code would be nice.

Quote
Does that mean everything between 3190-A48F and 20000-2FA1F can be split anywhere?

It is, yes.

mortstev

  • Posts: 7
Re: Suggestions for 3.9
« Reply #355 on: 15 Aug '17 - 20:55 »
The skins were received, thanks. I don't seem to be able to reproduce the problem though. Do I need to make some changes to the skin's skinconfig.txt file? If so, please give those too.

No. No changes to the  skinconfig.txt file are needed.

Maybe a little better description of the problem will help...
The hour seems to get cut off if you drag and drop into the player. Also it appears more often if there is only one sound file over an hour in length being dragged and dropped, but not always, sometimes if you drag and drop a bunch of short files (~4-5 minutes each maybe 6 of them) and with a couple of long (over an hour) length files it cuts the hour number off. If there are already entries in the playlist over an hour and you drag another entry over an hour in length into the playlist it resizes that column to accommodate the 'hour' - I hope that makes sense, if you need anything more let me know.

Also unrelated, but can an option to display the MP3 Tag Version (ie. ID3v2, ID3v1, APEv2, etc.) be added to the Info display-maybe as part of 'skinconfig.txt' in the form of 'pos_infoIDver' to display or hide the ID Version.

Thanks for your help.

Mort


mortstev

  • Posts: 7
Re: Suggestions for 3.9
« Reply #356 on: 18 Aug '17 - 21:21 »

Okay here's how I've been able to consistently reproduce the problem with the 'hours' column...

I've uploaded to the ftp site a file with the mp3 files I've noticed the problem it's called "hourproblem.zip" I also re-uploaded a files called "aaskins.zip" to be sure you have the exact same skin files as I do and included in there is my "xmplay.ini" (in case there's something in there that's unique to my system, one last thing I'm using XMPlay version 3.8.2.30.

Start by opening XMPlay and setting the 'album-art' skin, open the playlist (if not already opened) then closing XMPlay then:

1) open xmplay, open the playlist (should already be opened), right click on the "X" (next to 'random' on the righthand side of the playlist panel) and select 'remove all', exit xmplay

2) start xmplay, select all the files in the 'hourproblem' folder, drag them into xmplay and release them over the 'loading....' position bar (I don't know if this really makes any difference).

The image file "hourcolproblem.gif" shows the results with the hours column missing.

I hope this helps... doing it this way I've been able to reproduce the cut off 'hours' column 100% of the time. Also, if you remove the files from the list and then drop the files back into the player without exiting and restarting the player it loads the 'hour' column correctly - I believe this problem is somehow related to the mp3 files being cached and how long it takes to read the MP3 ID Tags and determine the length of the file. Also the problem is reproducible by dragging the 'zip' file into the xmplayer instead of the uncompressed files. One final thing I first noticed this loading sound files from a USB stick, but I've since done it from hardrives, SSD as well as RAM drives and as long as the files aren't cached I've been able to reliably reproduce it.

FWIW... I have the parameter "PlayDelay=3" set in the 'xmplay.ini' file, but in changing it to different values it doesn't appear to have any effect on the problem.

Also... there seems to be a problem with the way CUE files are handled. In that directory is a cue file named "03. Cue_File.cue" if you drag it into the player nothing happens, but if you rename it to "03. Apollo-13-Problem.cue" and then drag it in the player it works fine... somehow the 'FILE' portion in the cue file is  being ignored and for some reason the name of the cue file has to match the name of the MP3 file. Cue files are just plain ASCII text and can be opened with with Window's notepad and you'll see the 'FILE' name set correctly. I probably didn't do a very good job explaining the problem, but if you drag the cue file into the player then rename it and do the same thing I think you'll see what I'm talking about. :)

Another suggestion... sorry I'm being a pest! :) But, can the playlist panel be made to 'snap' against the edges of the XMplayer? Makes positioning it with the player a whole lot easier.

Thanks, again for putting up with me! :)

Mort
--