track entries on UTF-8 playlists seem cut and look like "1. p3", "2. p3"...

[surfer]

i installed the newest built 18207 on my IPOD 80GB and the track entries on my UTF-8 playlist look like:

1. p3
2. p3
...and so on.

this is only the case when i view them on my ipod under rockbox (all the track names on those playlists are there and ok when viewed in a text editor).
when i play such an entry it becomes again the wright name of the track.

other playlist that are not UTF-8 are ok.

i had no such issue at least until the build Version: r18093-080719 and when i install this build everything is ok again.

[bluebrother]

I'm not sure if I get your problem correctly. How are you viewing the playlist: using the text editor or the playlist viewer? What exactly do you mean by "becomes again" when playing? Do those playlist play fine on the player?

[surfer]

- i view the playlists under rockbox with the playlist viewer by holding-select on a playlist and pressing playlist/view afterwards,

- i also opened the playlists in a text editor under winXP (Ipod connected to USB) and the paths/names of the track entries on them are all ok.

What exactly do you mean by "becomes again" when playing?

i have to say that i'm a bit confused about that now because something pretty strange happend:
i noticed the problem when i installed the "current build" some days ago. But although the first entry on the playlists was "1.p3" i could start playing it (when viewing some of the playlists) and this first entry became again (changed to) the correct entry name as it was originally there (for example: "1.p3" changed to "1. summertime"). unfortunately i did not try it with any of the next track entries on those playlists.
(afterwards installed the build 18093 from a backup and averything was ok again)

but now, with the newest current build it does not work this way any more.

so now i have the first track entry on some of the playlists with the correct name of the tracks but the next ones are still "2. p3", "3. p3"..., and i can play those first tracks but not the next ones. i can start those playlist selecting them for playling as a whole as well but then again: only the first track will play but not the next ones.

On the other hand those playlist on which i did not try to play the first tracks earlier cannot be played at all

[spike66]

I had the same problem when I updated to Surfer's mentioned revision on my iPod video 80GB(and from there on), that is, when I load a playlist from the playlist catalog (I only have UTF-8 playlists), only the first track "is recognized" and can be played, the rest are seen through "view current playlist" as Surfer describes (#. p3). If shuffle is on, only the first track in the original (unshuffled) playlist is recognized, regardless of the position assigned in the shuffled playlist.

The original playlist files remain OK, as can be seen when using the text editor to browse them.

When playing folders through file browsing, playback works fine and all tracks in the folder are shown & played correctly; the generated dynamic playlist works fine.

[bluebrother]

can you post an affected playlist somewhere? I seem to fail reproducing the issue for myself.

[Lear]

I've seen this problem too, and I'm pretty sure the problem is that the playlist begins with a BOM, which causes the in-RAM index to be incorrect (point to the wrong parts of the playlist file). If so, the recent UTF-8 unification is the cause, and more specifically, the removal of the line "i += BOM_SIZE;". Easy to add back, to the if statement at line 536 in playlist.c. I don't have access to a development environment right now, so I can't test it myself.

By the way, it almost looks like the patch was never tested with a playlist containing a BOM... 

[bluebrother]

I've tried putting back the BOM line and it seems to fix the issue. No idea why I haven't observed the problem myself before (maybe I fooled myself by using a playlist with three similar tracks and using the default repeat setting ... should've used an album).
Nevertheless I don't really understand why add_indices_to_playlist() would need to check that -- IIRC if that happens the playlist has been opened without BOM checking in the first place and it should rather get changed there. Or is there something I'm missing? Ok, figured it. Man do I feel stupid ...

Edit: yep, I fooled myself with my test playlist. D'oh! Committed a fix ...

[spike66]

can you post an affected playlist somewhere? I seem to fail reproducing the issue for myself.

I was about to post a playlist but it's obviously no longer necessary... so thanks bluebrother and Lear, it's working just fine now 

[surfer]

yea...it works fine again, thanks a lot bluebrother & Lear! :-)