I have most of my music in WMA format and this is mostly working really well with Firefly and 2.5B10 firmware (on a M1001 Soundbridge).

I have found one album - only ONE out of about a dozen albums I've looked at - where the track order is displayed incorrectly by the combination of Firefly+Roku; all the other albums (all WMA) are displayed in the correct track order.

I am not sure what is "special" about this album, vs the others which are showing in correct order. When viewed in Windows Media Player or WinAMP, the track order is correct and the actual track tags look perfect. It has 39 tracks in it (rather more than any others I have looked at so far) and when I "show track info" on the Soundbridge when serving the album via Firefly, many/most of the tracks are showing up as being Track: 3" (rather than their actual track number, which may well be in the thirties range).

As I said above, I'm not sure why this one album would be a problem since its tags appear to be just fine (and no different from the albums which are showing in the correct order). I'm not sure what to do to narrow it down, but maybe someone else is seeing the same thing (on just some of their music) with Firefly and between us we can isolate it enough to get the bug fixed.


ted.h.

This has been resolved, and the fix will be present in the next test version. Thanks for the report and assistance.

-- Ron

rpedde wrote:

This has been resolved, and the fix will be present in the next test version. Thanks for the report and assistance.

New version posted at http://nightlies.mt-daapd.org/, with this fix in it. You'll have to delete your songs.db to force a rescan of the .wma files, but I'd be interested in hearing any feedback.

-- Ron

rpedde wrote:

rpedde wrote:

This has been resolved, and the fix will be present in the next test version. Thanks for the report and assistance.

New version posted at http://nightlies.mt-daapd.org/, with this fix in it. You'll have to delete your songs.db to force a rescan of the .wma files, but I'd be interested in hearing any feedback.

-- Ron

I just updated to the new svn-1018 nightly build, deleted songs.db so it would rescan, and now a quick check of the album that was wrong before (and also one which was correct before, just in case) shows it as being presented in the correct track number order now with the new build.

Thanks,
ted.h.

I just stumbled over another track order problem (with WMA files). On one album (that I have found so far), Firefly+Roku is showing the track number of two tracks both as 10, but in Windows Media Player and any tag editor I can find, they are correctly shown as 9 and 10.

No other tracks in the album have wrong or duplicated track numbers and there doesn't seem to be anything "special" about that one track - the whole album was ripped from CD at the same time and with the same settings.

Serving the same album (same physical files from the same Win32 server) via Twonkyvision 3.1 to the same SoundBridge shows all the track numbers perfectly too (ie the reporting of track 9 as track 10 only happens when serving from Firefly, and identically whether served over RSP or DAAP protocol also).

So it looks like a further small WMA tracknumber tag parsing issue still in Firefly, but an odd and probably really isolated one.

EDIT/Update: I just found that Firefly is showing the tracks in Dark Side of the Moon (WMA, would have been ripped from CD a long time ago) in correct track order BUT with ALL the track numbers one too high (ie same issue as track 9 being reported as track 10 above). That is, Firefly has the tracks numbered 2-11, but every other player and tag editor shows them as 1-10.

THOUGHT: Could it be that Firefly has an issue with WM/Track vs WM/TrackNumber tags? WM/Track is 0-based, WM/Tracknumber is 1-based, and according to MSDN WM/Track is obsolete and should be ignored if a WM/TrackNumber tag exists in a file? I edited and resaved each the DSOTM tracks in Mp3tag (with no visible change to the track number as shown anywhere else) and deleted songs.db and rescanned, then after that the track numbers are shown correctly by Firefly as 1-10. So there must be some parsing issue with "old" WMA files (ie ripped a long time ago), but I guess if edit/saving them in MP3Tag cleans up the tags so that Firefly likes them that is an ok workaround.


ted.h.

Ted Harper wrote:

THOUGHT: Could it be that Firefly has an issue with WM/Track vs WM/TrackNumber tags? WM/Track is 0-based, WM/Tracknumber is 1-based, and according to MSDN WM/Track is obsolete and should be ignored if a WM/TrackNumber tag exists in a file? I edited and resaved each the DSOTM tracks in Mp3tag (with no visible change to the track number as shown anywhere else) and deleted songs.db and rescanned, then after that the track numbers are shown correctly by Firefly as 1-10. So there must be some parsing issue with "old" WMA files (ie ripped a long time ago), but I guess if edit/saving them in MP3Tag cleans up the tags so that Firefly likes them that is an ok workaround.

I "thinkoed" that one, and was preferring wm/track over wm/tracknumber. Fixed in svn, will be present in next nightly.

Still, I was getting the zero based versus 1 based right, so I'm not sure what the issue was. It would be interesting to see if the wm/track really *was* incorrect on the original tag.

If you see any more of these, save one for me... I'd like to see the metainfo on it.

-- Ron

rpedde wrote:

Ted Harper wrote:

THOUGHT: Could it be that Firefly has an issue with WM/Track vs WM/TrackNumber tags? WM/Track is 0-based, WM/Tracknumber is 1-based, and according to MSDN WM/Track is obsolete and should be ignored if a WM/TrackNumber tag exists in a file? I edited and resaved each the DSOTM tracks in Mp3tag (with no visible change to the track number as shown anywhere else) and deleted songs.db and rescanned, then after that the track numbers are shown correctly by Firefly as 1-10. So there must be some parsing issue with "old" WMA files (ie ripped a long time ago), but I guess if edit/saving them in MP3Tag cleans up the tags so that Firefly likes them that is an ok workaround.

I "thinkoed" that one, and was preferring wm/track over wm/tracknumber. Fixed in svn, will be present in next nightly.

Thanks, BTW the page I have bookmarked as Microsoft's guidance on the usage guidelines for various WMA tags (including wm/track vs wm/tracknumber) is at http://msdn.microsoft.com/library/defau ... _usage.asp

(aside and feature request: While you're actively looking at WMA tags and parsing, I would love to see a "smart playlist" in Firefly based on WM/SharedUserRating in WMA files (ie so I could have a 4- and 5-star auto-playlist); guidelines mapping the tag values to the number of stars shown in Windows Media Player are in the detailed decription of the tag on that page), obviously mixed in with whatever the equivalent tags in other media formats are for star-ratings of tracks).


ted.h.