Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[monkbroc]

Hi,

I want to report an issue I've been having since I started using JRiver Media Center. I finally figured out what was wrong today.

When I accessed the Album view in Gizmo on Android, instead of displaying a grid of albums with album covers, I saw a list of tracks (but not all tracks, a smaller subset). I did not see this in the main Windows MC interface or in WebRemote (in both places the Album view was displaying as expected).

It took me a long time to track down the file that was causing the issue. The file in question had a bad character in the album field of the ID3 tag: character 0x0e. In the main MC interface, this character showed up as a music note. In WebRemote viewed in Firefox, this character showed up as a square box. However, it appears to have chocked Gizmo more seriously.

Obviously the workaround is to fix my broken tag. Now that I've done that the Album view in Gizmo works fine. But I thought I'd report this issue so you can get to the bottom of it.

Instructions to reproduce the bug:
- Open an MP3 file in a hex editor. Change one character from the Album ID3 tag to 0x0e (might have to be done in more than one place if there is an ID3v1 and ID3v2 tag).
- Open MC. See that the album name contains a music note
- Open WebRemote in the Album view. See that the albums are displayed properly, but the modified name contains a square box.
- Open Gizmo in the Album view. See the faulty behavior that the albums are not displayed, only a list of songs.

[Matt]

Nice detective work.  I see the same.

I think the music note vs square box is just a font thing depending on what's defined for 0x0e.

Currently we're just putting 0x0e in the UTF-8 string of the XML.  I'm not sure if the XML builder should be doing some escapement or if the Java in Gizmo is the problem.

[Matt]

This should be fixed in 17.0.89 or newer, hopefully coming in a few days.

Thanks for your help.