Bugzilla – Bug 7055
some tracks have no year information anymore -> after musicip import removed it
Last modified: 2009-07-31 10:16:54 UTC
problem: these tracks had no "year" information, although they are properly tagged and SC is able to extract this metadata from the track (mp3, flac, whatever) while scanning - and it works fine without musicip. cause: while importing these tracks into musicip (running in headless mode on this machine) some track infos which where pulled from the internet (musicbrainz?) had no "year" info - not all, but some. So this empty "year" attribute overwrote the already known and valid value for year. solution: just update the year information if musicip has this information. applied this patch and did a full rescan. patch: $ svn diff server/Slim/Plugin/MusicMagic/Importer.pm Index: server/Slim/Plugin/MusicMagic/Importer.pm =================================================================== --- server/Slim/Plugin/MusicMagic/Importer.pm (revision 17367) +++ server/Slim/Plugin/MusicMagic/Importer.pm (working copy) @@ -273,7 +273,7 @@ $attributes{'BITRATE'} = $songInfo{'bitrate'} * 1000; } - $attributes{'YEAR'} = $songInfo{'year'}; + $attributes{'YEAR'} = $songInfo{'year'} if $songInfo{'year'}; $attributes{'CT'} = Slim::Music::Info::typeFromPath($songInfo{'file'},'mp3'); $attributes{'AUDIO'} = 1; $attributes{'SECS'} = $songInfo{'seconds'} if $songInfo{'seconds'}; wish: please add this patch :-) thanks and kind regards, Markus
Markus - did you say the year value is in the file, but not in MIP's database? If MIP is overwriting valid values, isn't this a MIP bug? Did you report it to Predixis? We can of course implement work arounds for MIP's bugs, but that's no solution. And then we should probably define in whom we trust more: our scanner or MIP? We should imho _not_ overwrite a value with MIP's value, if we found something ourselfs.
Would you mind sending me a small sample file which shows this behaviour? Also: are you using the latest MIP?
- the year is part of the tag which is successfully recognized by SC (no problem) - musicip either asks some internet databases or in case it's not found there, fingerprints the file itself - the problem emerges if the tags imported from the internet databases includes NO year information, i.e year is empty - although SC has successfully scanned the track, the year-information is overwritten with an empty value - my patch does not overwrite any year informations, just makes sure it's not deleted/zeroed if MIP doesn't provide one. - i'm using the latest MIP... - Do you still need a sample file?
> - musicip either asks some internet databases or in case it's not found there, > fingerprints the file itself > - the problem emerges if the tags imported from the internet databases includes > NO year information, i.e year is empty Please report this to Predixis/MIP, as this seems to be a bug on their side. > - Do you still need a sample file? Yes please.
i'll attach a sample file later... btw. it's the same problem + solution as with "seconds" and "genre" (a few lines above/below in importer.pm), e.g. ... $attributes{'SECS'} = $songInfo{'seconds'} if $songInfo{'seconds'}; ... my interpretation: just update SECS in the SC-Database if it's set/known while querying MIP's API otherwise leave SECS as they are*. I'm little bit unsure if we have the same understanding on this problem. IMHO the fault is not withing MIP-Scan routines, but some incomplete entries in a Internet-Music-DB (which MIP queries). Nevertheless i'll ask Predixis why MIP doesn't get a year tag at all - and they'll probably tell me whoever added this track didn't provide one :-) *In my opinion this is the correct logic: update the SC-Database with values from 3rd-Party Sources (MIP, iTunes) but do not erase values form the SC-Database if they are not provided by this external Source. Okay, you could always force the external Source to provide 100% correct AND complete values but thats a bit unrealistic. As long as this does not touch key attributes like artist, album, ... thanks for listening :-)
for the sake of completness i've attached one of the problematic tracks. please remove it after download/tests as i don't want to go into prison ;-) the mmm-song-data.txt (part of the process while importing musicip data) contains the following record with no year key: --- name Mr. Larkin artist State Radio album Us Against the Crown album-id 138052440 file ....path to file..../02 - Mr. Larkin.mp3 genre Rock track 2 active yes seconds 246 bytes 4938334 bitrate 160 composer Chadwick Stokes modified 1199638922 added 1199639280 --- Unfortunately i was unable to reproduce the erroneous import on another MusicMagic Installation - although another version on a different OS, i.e the year information was successfully imported into the MIP-DB. Despite this fact i'm still considering my reasoning valid. btw. i was wrong when stating "it's the same problem + solution as with "seconds" and "genre"", it's the case with seconds only but not with genre. sorry.
Created attachment 2842 [details] mp3 track
Can't reproduce this. Did you tag the file after it's been analyzed by MIP? Here's what I'm getting: name Mr. Larkin artist State Radio album Us Against the Crown album-id 342015312 file /Users/mh/Music/tests/beingoverwrittenbymip.mp3 genre Rock track 2 active no seconds 246 bytes 4938334 year 2005 bitrate 160 composer Chadwick Stokes modified 1202903169 added 1202903262 The year is in there, and correctly exported. The question remains though, whether MIP should overwrite existing values.
Created attachment 2859 [details] correctly imported song
Could you please enable debugging for plugin.musicip and upload the log file?
Created attachment 2860 [details] don't overwrite SC data if MIP doesn't offer any information for a given tag would this fix the issue for you?
Created attachment 2883 [details] logfiles from MIP Import with plugin.musicip=debug logfiles from MIP Import with plugin.musicip=debug
sorry for the delay... > Can't reproduce this. Did you tag the file after it's been analyzed by MIP? I'm really, really, sure i didn't do this. Im absolutely trying to avoid all the hassle with subsequent tagging, updated modification attributes on the files, and so on, but > Here's what I'm getting: > > name Mr. Larkin > artist State Radio > album Us Against the Crown > album-id 342015312 > file /Users/mh/Music/tests/beingoverwrittenbymip.mp3 > genre Rock > track 2 > active no > seconds 246 > bytes 4938334 > year 2005 > bitrate 160 > composer Chadwick Stokes > modified 1202903169 > added 1202903262 > > The year is in there, and correctly exported. i can confirm i get the same positive results, if starting from scratch (empty mip-db, empty sc-db). So somehow my mip-db is incomplete howerver i don't know how this happened. Maybe it's time to rebuild the DB, although i'll probably take a few days again. This problem affects about 5% of my library. > Could you please enable debugging for plugin.musicip and upload the log file? logs.zip contains two directories, one with the logs form my small db with the album's directory beeing the base for MIP and SC. The logfile from the other directory has all tracks removed not containg the appropriate album title. > don't overwrite SC data if MIP doesn't offer any information for a given tag > would this fix the issue for you? yes! this fixes my problem, i.e all year informations are retained even after importing my (partial) MIP-DB. thanks!
change 17759 - only overwrite DB values if MIP has a value defined
thanks very much!
(In reply to comment #15) > thanks very much! > Verified fixed in 7.0.1 - 19325
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1 Please try that version, if you still see the error, then reopen this bug. To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html
Reduce number of active targets for SC