Bugzilla – Bug 599
Musepack files not getting tags read
Last modified: 2009-09-08 09:21:34 UTC
ALL my Musepack files are tagged, but when music folder is scanned, SlimServer does not recognize them and does not include them in any of the "Browse" lists. I can Browse music folder directly, find them and play them, but they are not automatically included when browsing by genre and the like.
Created attachment 162 [details] Sample musepack file
KDF: This should be fixed with your upcoming checkin, right?
This is a dupe of bug589 and bug450 and its fixed in nightly and upcoming 5.3.1
sorry...that's bug592 (592) and bug450 (450)
usign latest cvs, this attached file saved as "sample.mpc", comes up as Saphire, by Bill Douglas, genre: New Age, 190kbps bitrate. you will need the latest build, Oct 2 is a good one to do becuase it will automatically rescan. Marking this as fixed, but please reopen if you have any other issues with MPC tags.
Installed latest nightly build (10/2) per last comment, but rescanning music folder seems to kill the server about 5 minutes or so into it. This occurred with the 10/1 build as well. Going back to released 5.3.0 version.
The nightly fix for the original problem works great, thanks for the change.
so is there a problem to fix, or do we just ignore it? please send a log of the crash.
I've confirmed it is the Musepacks causing the crash. I installed the 10/3 build of 5.3.1. I removed all folders that had musepacks in them (I've got 5) and rescanned. The scan was successful for only mp3s. I just tried putting one of the folders of musepack files back in (this folder's first artist is Bill Douglas; the artist I submitted the sample.mpc for). The folder name begins with a '#' sign, so it is first in the music folder. Not sure if that makes a diff or not, but I assume it does since when I then tried to rescan, it took a mere 30 seconds or so to crash the slim server. Which debugging options do you want me to select, and how do I get the log out to a file? I tried lgging earlier and once it crashed, I couldn't find the log. Thanks.
the default log under linux is /tmp/slimserver.log it would also be good to know the exact song that is causeing the crash. You can also see what the crash message is if you simply run the server from the command line and watch the console. as for debug, d_info would likely be the most useful. it might hint at what particular part of scanning a file is triggering the crash. These alternate formats like to revamp their codecs a fair bit so there might be a header version that I haven't got on hand to test and its messing with the existing routines.
if it is still crashing, you can lookin /tmp/slimserver.log, or the windows event viewer. for debugging, try running: c:\program files\slimserver\server\slim.exe --d_info --logfile c:\mylog.txt when the server starts, go into the browser UI, server settings, performance and hit wipe cache. When it crashes, you will have a log in c:\mylog.txt. All we should need to see is the last 20 lines or so where it crashes.
I logged the crash. Thanks. The first time, I could easily see which file caused it. I moved it out of the way and tried again and crashed on a different file that time. I can clearly see that it appears the files may be corrupt, but is there a way I can tell for sure other than doing this exercise repeatedly, removing the bad ones as I go??? The last few lines of each log follow: *********** First log *********** 2004-10-09 08:12:50.2950 Request for CT on file file:///D:/MP3/Tunes/% 23NewAge&Ambient/BillDouglas-Kaleidoscope(MusePack)/04-BillDouglas-Voyage.mpc 2004-10-09 08:12:50.2958 cache miss for file:///D:/MP3/Tunes/% 23NewAge&Ambient/BillDouglas-Kaleidoscope(MusePack)/04-BillDouglas-Voyage.mpc 2004-10-09 08:12:50.2975 Converting file:///D:/MP3/Tunes/% 23NewAge&Ambient/BillDouglas-Kaleidoscope(MusePack)/04-BillDouglas-Voyage.mpc to D:\MP3\Tunes\#NewAge&Ambient\BillDouglas-Kaleidoscope(MusePack)\04- BillDouglas-Voyage.mpc 2004-10-09 08:12:50.2989 mpc file type for file:///D:/MP3/Tunes/% 23NewAge&Ambient/BillDouglas-Kaleidoscope(MusePack)/04-BillDouglas-Voyage.mpc 2004-10-09 08:12:50.2996 Updating cache for: file:///D:/MP3/Tunes/% 23NewAge&Ambient/BillDouglas-Kaleidoscope(MusePack)/04-BillDouglas-Voyage.mpc Negative length at /PerlApp/Audio/APETags.pm line 169. ****** Second Log *********** 2004-10-09 08:12:50.2950 Request for CT on file file:///D:/MP3/Tunes/% 23NewAge&Ambient/BillDouglas-Kaleidoscope(MusePack)/04-BillDouglas-Voyage.mpc 2004-10-09 08:12:50.2958 cache miss for file:///D:/MP3/Tunes/% 23NewAge&Ambient/BillDouglas-Kaleidoscope(MusePack)/04-BillDouglas-Voyage.mpc 2004-10-09 08:12:50.2975 Converting file:///D:/MP3/Tunes/% 23NewAge&Ambient/BillDouglas-Kaleidoscope(MusePack)/04-BillDouglas-Voyage.mpc to D:\MP3\Tunes\#NewAge&Ambient\BillDouglas-Kaleidoscope(MusePack)\04- BillDouglas-Voyage.mpc 2004-10-09 08:12:50.2989 mpc file type for file:///D:/MP3/Tunes/% 23NewAge&Ambient/BillDouglas-Kaleidoscope(MusePack)/04-BillDouglas-Voyage.mpc 2004-10-09 08:12:50.2996 Updating cache for: file:///D:/MP3/Tunes/% 23NewAge&Ambient/BillDouglas-Kaleidoscope(MusePack)/04-BillDouglas-Voyage.mpc Negative length at /PerlApp/Audio/APETags.pm line 169.
Created attachment 175 [details] 1st file to crash server
Created attachment 176 [details] 2nd file to crash server
Apologies. Second file to crash server is logged below: 2004-10-09 08:15:10.2616 Request for CT on file file:///D:/MP3/Tunes/% 23NewAge&Ambient/ChrisSpheeris-Desires(MusePack)/02-ChrisSpheeris-Viva.mpc 2004-10-09 08:15:10.2624 cache miss for file:///D:/MP3/Tunes/% 23NewAge&Ambient/ChrisSpheeris-Desires(MusePack)/02-ChrisSpheeris-Viva.mpc 2004-10-09 08:15:10.2641 Converting file:///D:/MP3/Tunes/% 23NewAge&Ambient/ChrisSpheeris-Desires(MusePack)/02-ChrisSpheeris-Viva.mpc to D:\MP3\Tunes\#NewAge&Ambient\ChrisSpheeris-Desires(MusePack)\02-ChrisSpheeris- Viva.mpc 2004-10-09 08:15:10.2652 mpc file type for file:///D:/MP3/Tunes/% 23NewAge&Ambient/ChrisSpheeris-Desires(MusePack)/02-ChrisSpheeris-Viva.mpc 2004-10-09 08:15:10.2659 Updating cache for: file:///D:/MP3/Tunes/% 23NewAge&Ambient/ChrisSpheeris-Desires(MusePack)/02-ChrisSpheeris-Viva.mpc Negative length at /PerlApp/Audio/APETags.pm line 169.
hi chris. thanks for the log. I'm certain I can put in a quick safety check to avoid teh "negative length" problem. I'm not able to get at it right away, but I'm guessing you might prefer a nightly. I'll put something in for tomorrow that will either fix it, or give a more useful report without crashing.
i've tried both these attached files, to create a safe patch to avoid a crash. i opened up these files into Tag&Rename (3.1.5 supports APE). Tag&Rename shows no valid tags for those two files. Looking at the hex code, it looks as if there is an APETAGSX header twice over. You may want to try double-checking the method you are using for tagging to make sure the tags aren't somehow corrupted.
Thanks for your help all. By launching from the command line and logging, I managed to catch 12 files that kept wanting to bring the server to its knees. I've gotten the rest scanned and the tags look great. This can be closed.
thanks. if you do manage to find out at any point why those tags might have been corrupt or otherwise unreadable, please feel free to reopen to have support added.
I'd also like to make sure that these files don't bring the server to its knees. Does KDFs fix solve this problem for you for all 12 files?
Just tried the 10/14 nightly to no avail. I moved all the ones I found to have been causing the trouble before into a TEST folder, set that as my Music Folder and tried to Wipe cache. It didn't crash the server, as the GUI remained up, but the interface did seem locked up and task manager reported minimal activity for the server process. Killed the GUI and server, restarted and set the Music Folder back to original and am currently rescanning successfully.
I'd also be interested in getting rid of the warning if those tags are in fact a normal occurence instead of corrupt.
I'm confused by this. The fix is supposed to check the tags and skip any file with a tagsize that registers as larger than teh filesize. This matches with the two supplied files. With this fix, neither of those files stops teh server from operating. The 12, if they are the same as these should not be causing any blockage in neither the scan or the web UI.
as an example, here some debug output from my scan of /mnt/mp3/Alternate/MPC as my music folder of 68 songs, and includes the two sample bad files: tagTotalSize error, these do not appear to be valid APEtags at /usr/local/slimserver/CPAN/Audio/APETags.pm line 167. tagTotalSize error, these do not appear to be valid APEtags at /usr/local/slimserver/CPAN/Audio/APETags.pm line 167. 2004-10-14 19:06:26.2980 Completing folder Scan in 1.84709000587463 seconds 2004-10-14 19:06:26.3821 Finished background scanning at 1.93711805343628 seconds.
chris, can you run the test again, using slim.exe --d_info --logfile c:\mpcinfo.log, and attach the contents of that log. the sample files arent' causing ANY server lag for me, so this is at a dead end without more info
Created attachment 181 [details] File causing MB of logging
Created attachment 182 [details] mpcinfo.log
Set the musepack "bad" folder back to music folder and wiped cache. I noticed the mpcinfo.log file growing exponentially after only about 10 seconds, so i killed the server at the command line and looked at the tail of the log. I think it will be clear that what happened shouldn't have. I edited the attached mpcinfo.log to include the last three files it worked on and only some of the output that wanted to fill up the hard drive. I also attached the file I believe is the culprit (at least this is "one" that is probably doing this). Anxious to see what you guys find. Thanks a lot.
testing the new sample file, I only get the warning that says there is a tagsize error (as per the recent patch), but not looping as shown in the included log. Can you confirm that this file is a problem for you, maybe just have it alone in the audiodir. Have you been able to re-rip these files in a way that doesn't cause you a problem or is this reproducable on new files that you are encoding?
sorry, the first download of the file seemed to have barfed. redownloaded and can now reproduce.
I've comitted a fix that will give a warning when the header isnt found. The loop was being caused becuase the APEtags module thinks the header is at the start of the file so it gets a completely crazy set of numbers, thus looping hundreds of thousands of times. we'll warn and consider this tag problem as corrupt tags for now. I'd really like to know how you created these files so I can try to parse the info properly. I can see it there, but its not where it should be, and the is additional data that shouldn't be there.
I may have a fix that will get the right tags from the files, but I'd like to know if what has been done so far clears up all your hanging and crashing problems, and maybe some info on how you created these files. I also have to do some more research to make sure that what I'm planning to try is actually within spec and not just faking a way past corrupt tags. What is happening is that your files appear to have ID3V1 tags at the end of the files. Now, from the slimserver code, the APETag should be before the ID3V1, but instead the APETags appear to be written over the last 32 bytes of the ID3V1 tags.
I didn't really do anything unusual when I made these. I was trying different formats when I ripped them using Exact Audio Copy. The only thing I can think of that might have caused the location problem with the ID3 tag is that I sometimes use The Godfather to manage my tags. Maybe I created MP3 tags too on some of them and The Godfather app put them in the wrong spot in the file. Is your build part of the latest nightly? I'll give it a shot with the rest of my "problem" files and see how it goes. Thx
The latest nightly was built at 2am, so the patch should have made it in. Its still considered a temporary patch to give warnings until the actual problem can be fixed. Use that version to see if at least you avoid teh infinite loop or any crashing. I have another fix that seems to pull the tags out corectly, but I'm concerned about comitting that because there are other programmes that also say thetags from your sample files are not available. Its not so much the worry that the APEtags are at the end, instead of just before the ID3V1, but its the fact that the APEtags have obliterated the last part of teh ID3V1 tags. Dean, do you have a stance on supporting something like this? I'll send a note to Dan to see what he thinks about making this kind of change to a CPAN module.
Last night's build worked beautifully!!! Awesome job you guys. Again, I wish I had more detail about how/why these tags may have gotten corrupted. The rest of my collection is fine (or so I imagine...) Thanks again.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.