devsnd
Display album art when playing
Hi! i´m having trouble with the feature "Display album art when playing"
All my files has its cover through id3tag. Even inside each folder, there is a folder.jpg file with the cover. I´m running cherryserver under Windows Server R2 64bits,
the result for cherrymusic --info is:
E:\cherryMusic\cherryMusic>python cherrymusic --info CherryMusic Server 0.34.1
CherryPy: 3.6.0 Python: CPython 3.4.3 Platform: Windows-2008ServerR2-6.1.7601-SP1
configuration dir:
- C:\Users\Administrator\AppData\Roaming\cherrymusic* server data dir:
- C:\Users\Administrator\AppData\Roaming\cherrymusic* static resources dir:
- E:\cherryMusic\cherryMusic* server package dir:
- E:\cherryMusic\cherryMusic\cherrymusicserver* process working dir:
- E:\cherryMusic\cherryMusic*
locale: (None, None), default: ('es_AR', 'cp1252') filesystem encoding: mbcs
(Do not parse this output.)
E:\cherryMusic\cherryMusic>
Am i missing something?
Hi tacul, thanks for opening a ticket and taking the time to collect that information.
What exactly is the trouble? I take it you don't see the images in the player area? It would be helpful if you could go into more detail here. What exactly is wrong? Does it happen all the time, or just in some cases? (Which?) Do folders have their proper images in the browser/search area?
Thanks for including the other information; that's helpful as well. :)
Well, thank you @tilboerner Sorry i didnt realize that information could be helpfull. Anyway:
It nerver work to me (i had the same library installed under Windows 7 but it doesnt worked either)
And yes, the folder have their proper images:
(that is a image inside the folder, not a fetched one, plus the mp3 have it in the id3tag)
Could it be an issue with ImageMagick under Windows? I already test it with the parameters suggested in the imagemagick web:
And it seems ok.
Do you have any other test i could do to indentify the trouble?
Thanks!
Hi tacul, thanks for your report!
I'll set up a virtual machine to see if I can reproduce this issue under windows. I don't know your level of expertise, but if you happen to know how to open the developer tools in your browser it would be very helpful to know what data your browser sends to the server and receives back, when you start playing a new track.
One thing would be even easier if this is indeed a client side problem: If you don't mind, you can give me access to your CM server, so I can try it out myself. Just send me username and password via mail to tomwallroth [aŧ] gmail [døt] com if that's okay for you. I won't judge your taste in music, I promise ;)
Hi Tom! If anyone is welcome to enter my CM, that's you! I have sent an email with the url and login credentials. Thanks!
Hey tacul, thanks for giving me access! It seems the client does not request the albumart from the correct directory and therefore does not load the correct image.
It tries to fetch the albumart from the base directory instead of fetching it from /api/fetchalbumart?data={%22directory%22:%22/%22} the directory of the track itself. I'll see what I can do.
Hey @tacul!
After some investigation I found the problem: All file paths in CM are transmitted using the OS-specific path separator, which is / in unix systems and \ in windows systems.
The album art fetching did only work for directories before. So to get the albumart for a specific file (the playing track) I was stripping the file name from the path to get the parent directory in of that file to get the album art for. I now changed it to be able to fetch album art for specific files.
Anyway, this should in turn fix your issue with the album art of the playing track. Check out the devel branch to see if it works for you, and if it does, feel free to close this issue!
Again thank you very much for the support: I don't own a windows machine and didn't even know how and why CM would run there and there are indeed some interesting edge cases like this one.
:bread: :sheep:
Sorry @devsnd but it still doesnt working for me.
You still have the credential to access my CM, feel free to check it wherever you want. And of course you can make any test on it!
Thanks Again!!!
Hey @tacul, sorry for the long delay! We're both pretty busy at the moment...
I think it's a good idea at this point to find out if TinyTag can actually read the image data. I'd like to try this on your system, so could you help me out with that?
Please run the following Python command in E:\cherryMusic\cherryMusic, substituting the full path to the mp3 file (starting with a drive letter, e.g. C:\PATH\TO\BASEDIR\Depeche Mode\[2005] Playing The Angel\01 - A Pain That I'm Used To.mp3):
python -c "import tinytag; data = tinytag.TinyTag.get(r'''FULL_PATH_GOES_HERE''', image=True).get_image(); print(len(data or []))"
This should cause the size of the image data to be printed to the screen. If you get a 0, TinyTag did not find an image; anything else indicates an error, which would be helpful to see.
Hi @tilboerner!!! well, this is what i got after run the Python Command.
I made three different test in different locations in case it exceeds the maximun letters path name.
Anything i can do to help, i will be glad!
@tacul: Seems there's an issue with tinytag. I made a pull request over there.
Edit: Just saw that there already exists a fix for the general case of this bug in tinytag: 6810ba02a. At this point, we only need to update the tinytag code in CherryMusic, I guess.
@tacul, I updated the tinytag version in our devel branch. Could you try out if the images display correctly using this branch?
