View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002220 | MMW v4 | Burning / Disc Handling | public | 2005-12-06 05:19 | 2007-04-04 21:17 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.0 | ||||
| Summary | 0002220: Burn Data CD: .m3u files aren't burnt as expected | ||||
| Description | One of the features in bug 2068 was that .m3u playlists can be created based on user configuration. The intent of this functionality was that users be able to navigate the CD by whatever attributes they wish using a set of .m3u files that provide access to all of the content. The actual implementation, though, is a bit different, generating .m3u files based on which nodes have been checked off rather than based on what tracks are actually on the Disc (e.g. if a playlist with 100 5 star tracks is on the disc, no .m3u files for Albums or Artists associated with those tracks will be created). A second (more minor) issue with the implementation is that when the .m3u files are organized by directory, they can be better optimized so that Artist and Album .m3u files aren't mixed together (see 3.1 below). This probably requires a bit of discussion. | ||||
| Additional Information | Based on testing of build 921 here's what has been implemented (along with a bit of commentary): 1) Burn Selected files + choose all .m3u playlist types --> no .m3u burned (playlists should have been burnt for all pre-Selected files) 2) Burn Selected + Artist (Aimee Mann) + Artist .m3u playlist types / prefix -->\Playlists\Artist - Aimee Mann - Album1.m3u -->\Playlists\Artist - Aimee Mann - Album2.m3u -->\Playlists\Artist - Aimee Mann.m3u OK, though it is arguable that only the third .m3u file (\Playlists\Artist - Aimee Mann.m3u) should have been burned (due to overpopulation of the directory). Also, playlists should have been burnt for all pre-Selected files. 2.1) Burn Selected & Artist (Alanis Morissette) + Album .m3u playlist types / prefix -->\Playlists\Album - Jagged Little Pill (Alanis Morissette).m3u -->\Playlists\Album - Under Rug (Alanis Morissette).m3u OK, except that playlists should have been burnt for pre-selected files. 2.2) Burn Selected & Album (?) + Album .m3u playlist types / prefix -->\Playlists\Album - <Album> (<Artist>) " 2.3) Burn Selected & Album (101 Depeche mode) + Artist .m3u playlist types / prefix -->\Playlists\Artist\Depeche Mode - 101.m3u 2.4) Burn Selected + Artist (Air) + Artist & Album .m3u playlist types / prefix --> \Playlists\Album - Jagged Little Pill (Alanis Morissette).m3u -->\Playlists\Album - Under Rug (Alanis Morissette).m3u --> \Playlists\Artist - Alanis Morissette - Under Rug.m3u --> \Playlists\Artist - Alanis Morissette - Jagged little Pill.m3u --> \Playlists\Artist - Alanis Morrisette.m3u This is another good example of how the directory becomes overpopulated when Artist & Artist-Album playlists appear together. 3.1) Burn Selected + Artist (Aimee Mann) + Artist .m3u playlist types / directories -->\Playlists\Artist\Aimee Mann - Album1.m3u -->\Playlists\Artist\Aimee Mann - Album2.m3u -->\Playlists\Artist\Aimee Mann.m3u This ok, though it is arguable that only the third .m3u file (\Playlists\Artist\Aimee Mann.m3u) should have been burned. Otherwise the directory becomes overpopulated. A better alternative when 'directories' is chosen would be: -->\Playlists\Artist\Aimee Mann.m3u -->\Playlists\Artist\Aimee Mann\Album1.m3u -->\Playlists\Artist\Aimee Mann\Album2.m3u 3.2) Burn Selected & Album (?) + Album .m3u playlist types / prefix -->\Playlists\Album\<Album> (<Artist>) 3.3) Burn Selected & Album (Stranglers - 10) + Artist .m3u playlist types / prefix -->\Playlists\Artist\Stranglers - 10.m3u This is a bit confusing. If the Artist chose an Album and Artist .m3u playlists, why is a playlist being burned at all? This would make sense if this approach was taken consistently (e.g. if the created .m3u files were always created based on whatever tracks were burnt rather than based on what was selected), but the current implementation seems to usually only create .m3u files based on _selected nodes_ (note: I'm not arguing to change this--only that I don't understand why we seem to be taking a different approach for this). 5) Burn Selected + Artist (Air) + Artist & Album .m3u playlist types / directories --> Playlists\Album\Afternoons in Utopia (Alphaville).m3u --> Playlists\Album\Forever Young (Alphaville).m3u --> Playlists\Artist\Alphaville - Afternoons in Utopia.m3u --> Playlists\Artist\Alphaville - Forever Young.m3u --> Playlists\Artist\Alphaville.m3u --> Playlists\Playlist\This is the dream of Evan and Chan.m3u This is consistent with the rest of the implementation, but lacking in the sense that tracks from the playlist cannot be accessed via other .m3u files, which was the original intent of this functionality--to be able to navigate the collection by whatever means the user chooses. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1027 | ||||
|
|
Minor correction re. point 3.1: 3.1) Burn Selected + Artist (Aimee Mann) + Artist .m3u playlist types / directories A better alternative when 'directories' is chosen would be: -->\Playlists\Artist\Aimee Mann\All.m3u -->\Playlists\Artist\Aimee Mann\Album1.m3u -->\Playlists\Artist\Aimee Mann\Album2.m3u Or if [x] Genre was enabled (it's currently missing) with 'directories': -->\Playlist\Genre\<Genre>\All.m3u -->\Playlist\Genre\<Genre>\<Artist>.m3u Basically, what I'm looking for is that the user should be able to browse the DVD much as they would browse their iPod, with the .m3u files acting as a virtual DB. |
|
|
Ok, as described in 2), 2.4), 3.1) the Artist directory becomes overpopulated due to burning of particular albums to this directory too (I implemented this cause I thought that Rusty want it this way). To prevent this no albums are burnt to Artist directory/prefix. Paricular albums are burnt _only_ to Album directory/prefix. Pre-selected.m3u is burnt everytime when [x] Burn .m3u playlists is checked. Fixed in build 922. |
|
|
This resolves the overfilling issues, however, I have a feeling that there's a bit of miscommunication here--the fundamental issues that I raised are still open. We may need to talk this over directly. What I mean is that: 1) Playlists are still being generated based on the nodes that the user has selected when they are choosing content, rather than based on what they've chosen in the .m3u options screen. e.g. Preselected: Carpenters - On Top of the World Selected Artist|Aimee Mann .m3u options: Playlist, Artist ; prefix --> \Playlist\Artist - Aimee Mann.m3u (this is correct) \Playlist\Pre-selected tracks.m3u (this is incorrect -- what should have been burned was Carpenters.m3u ) OR Select Playlist|4 Star Tracks .m3u options: Artist, Album, Playlist ; Prefix --> Playlist - 4 Star Tracks.m3u Preselected tracks.m3u But what's missing are .m3u playlists based on all the Artists and Albums that were included within the playlist so that the user can navigate the CD! To reiterate the point I raised in comment 6547: the user should be able to browse the DVD much as they would browse their iPod, with the .m3u files acting as a virtual DB. 2) The issue I'd previously raised in 3.1 in comment 6547 is still open. i.e. When the user chooses .m3u options: Artist ; directories, the Artist directory should be populated in the following manner: -->\Playlists\Artist\Aimee Mann\All.m3u -->\Playlists\Artist\Aimee Mann\Album1.m3u -->\Playlists\Artist\Aimee Mann\Album2.m3u Again: the goal here is to provide a means of easily browsing the content (in the hope that this implementation could be used for MP3 devices as well). At this point, the functionality sort of works (in a different way) and so I'm tempted to push this, unless it's a simple matter to resolve. |
|
|
Per discussion with Jiri, let's push this. The functionality will meet most users needs, though we'll certainly want to improve this for when this is integrated with portable devices (since many of them don't have a DB and a 'virtual DB' is very useful. |
|
|
I tend to -->\Playlists\Artist\Aimee Mann.m3u -->\Playlists\Artist\Aimee Mann\Album1.m3u -->\Playlists\Artist\Aimee Mann\Album2.m3u ..as Rusty have previously suggested. Fixed in build 924. |
|
|
Note: Ludek indicated that issue 2) was resolved as: -->\Playlists\Artist\Aimee Mann\All.m3u -->\Playlists\Artist\Aimee Mann\Album1.m3u -->\Playlists\Artist\Aimee Mann\Album2.m3u I don't believe that issue 1 has been resolved. |
|
|
Verified in 926. It's working nicely. Re-opening as 'high' for the Virtual DB functionality (item 1). This is for a future version of MM. |
|
|
Raised to 'urgent' for discussion with Jiri. This would be useful for portable devices that don't have DBs. Is it too complex to implement? If yes, I would agree to push it beyond 2.6 and we can just port the current CD Burning Playlist implementation to Device Synchronization. |
|
|
I think that there's more to be changed regarding this in synchronization and so it should be deferred for MM 2.6. |
|
|
This functionality is no longer working in build 1023. i.e. .m3u files aren't being burnt to the CD at all. |
|
|
Yes, thanks, this is one of other thinks which is caused by transition to hpcde > 2.0. After this transition whole burning behaves somehow unstable. I don't like the changes they make, because it affects our functionality :-( |
|
|
Their current SetImageLayoutFromFolder() method allways fails, I had to write my own. Now, it works fine again. |
