After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 570484 - iRiver E100 playlist generation incorrect
iRiver E100 playlist generation incorrect
Status: RESOLVED FIXED
Product: totem-pl-parser
Classification: Core
Component: General
2.25.x
Other All
: Normal normal
: ---
Assigned To: totem-pl-parser-maint
totem-pl-parser-maint
Depends on:
Blocks:
 
 
Reported: 2009-02-04 11:45 UTC by Hew McLachlan
Modified: 2009-02-08 02:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
set the filename offset correctly (2.57 KB, patch)
2009-02-06 02:55 UTC, Jonathan Matthew
committed Details | Review

Description Hew McLachlan 2009-02-04 11:45:38 UTC
Please describe the problem:
From https://bugs.launchpad.net/bugs/264156

Creating a E100 playlist in Rhythmbox places it in the root folder, rather than ./Playlists where it is detected by the device. 

After the playlist is manually moved, it appears to have corrupted filenames that range from just missing the first letter, to having only the extension on the end or even no name at all. The songs however are fine, and play correctly. 

Steps to reproduce:
1. Connect E100 (MSC/UMS mode)
2. Open Rhythmbox
3. Right click on player and choose "New Playlist"
4. Populate playlist with songs
5. Disconnect device and attempt to use playlist

Actual results:
No playlist can be found (unless it has been moved manually)

Expected results:
Playlist exists and can be played

Does this happen every time?
Yes

Other information:
Comment 1 Jonathan Matthew 2009-02-05 12:23:06 UTC
I've fixed the playlist path thing:

2009-02-05  Jonathan Matthew  <jonathan@d14n.org>

        * plugins/generic-player/rb-generic-player-source.c:
        (get_device_info):  The playlist_path hal attribute is sometimes a
        string and sometimes a strlist, so try both.  From #570484.

I'm seeing similar playlist corruption here, also using an iriver device.  The code (in totem-pl-parser) for writing the iriver playlist format has probably rotted a bit.
Comment 2 Bastien Nocera 2009-02-05 12:26:28 UTC
Possible indeed. Probably broke in the more recent GIO porting.

A test case to generate a playlist would be nice, and have something to compare it to.
Comment 3 Jonathan Matthew 2009-02-06 02:50:39 UTC
I finally figured out what the first two bytes of the playlist record are - they're the offset of the first character in the full file path to display when viewing the playlist on the device.  Currently we set it to 0x001A because that was the value I saw in the playlist I used to figure out the format.
Comment 4 Jonathan Matthew 2009-02-06 02:55:36 UTC
Created attachment 128069 [details] [review]
set the filename offset correctly

also updates my email address, fixes the debug output when URI->filename conversion fails (it would have displayed 'empty' instead of the problematic URI) and fixes a read-after-free in some debug output in an error case.
Comment 5 Bastien Nocera 2009-02-06 10:38:29 UTC
Please commit to trunk (and 2-24 if appropriate).
Comment 6 Jonathan Matthew 2009-02-08 02:59:39 UTC
Committed to trunk and 2-24:

2009-02-08  Jonathan Matthew  <jonathan@d14n.org>

        * plparse/totem-pl-parser-pla.c: (totem_pl_parser_write_pla),
        (totem_pl_parser_add_pla):
        The first 16 bits of the playlist entry record are actually the
        one-based offset of the first character of the filename.  Set this
        correctly (rather than always to 0x1A) so the playlists look right
        when viewed on the device.  (Closes: #570484)

        Also update my email address and fix a couple of debug output
        statements.