View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001949 | MMW v4 | Synchronization | public | 2005-07-07 17:18 | 2007-03-21 15:52 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.0 | ||||
| Summary | 0001949: More fine-grained control over auto-generated playlists | ||||
| Description | There are a couple of confusing/lacking areas in relation to the .m3u playlist creation functionality in MM 2.4.2. To understand the issues, let's review the usecases for which this feature is intended: a) Synch device with a DB, but no playlist DB synching (I believe the H320 is an example of this, since our plugin has 'Copy .m3u playlists' enabled by default, unlike the iPod plugin). b) Synch device without a DB, but a lot of space (e.g. PMP 140) c) Synch device without a DB, but a little space (e.g. most players) For a) The current functionality is problematic because when they try to synch a subset of their library, a bunch of playlists are needlessly generated (based on Artists/Albums selected). e.g. if user selects Artist=Beatles, then playlists will be generated unnecessarily for: Beatles.m3u Beatles-Revolution.m3u Beatles-Abbey Road.m3u Beatles-<other albums..>.m3u (I say unnecessary because the user can already navigate the Database to access these Artists or Albums via the default directory hierarchy!!) For b) The current functionality is decent, but lacking because: -If the user synchs a subset of the library, then as with the example above, Artist and Album playlists are needlessly created (needless, because although the device doesn't have a DB, the user can easily navigate the devices /<Artist>/<Album> hierarchy to play these tracks. -If the user synchs the entire library, then .m3u Playlists are created _only_ for MM Playlists, and there's no means of playing tracks based on Genre. For c) synchronizing a subset of the library works ok, except that the list of Playlists that are created is kind of cumbersome to Navigate because for any Artist that is selected multiple playlists are created even if there are a total of 3 tracks by an artist from 3 different albums. e.g. /Playlist/<Artist>.m3u /Playlist/<Artist>-Album1.m3u /Playlist/<Artist>-Album2.m3u /Playlist/<Artist>-Album3.m3u The problem is not that these playlists are created, but rather the manner in which they're organized. What we should do is create an implementation that: -For all devices, only creates playlists that are actually useful (i.e. only MM Playlists for a database-driven device; only MM Playlists, Genres, and Albums for non-database driven devices) -Create playlists in a more useful hierarchy This can be achieved via the following change to our current implementation. 1) Add Genres to the Synchronization list 2) Change the 'Copy .m3u Playlists' section of the Synchronization options to: Generate .m3u Playlists [x] Store Library Playlists to: \Playlists\ [x] Store Genres to: \Genres\ [ ] Store Artists to: \Artists\<Artist>\<Album> [x] Store Albums to: \Album Note: To simplify the above we can eliminate the storage location and simply use the default directory settings that appear above. e.g. Generate .m3u Playlists for: [x] Library Playlists [x] Genres [ ] Artists [x] Albums Destination Directory: _\__________________________ The only difference being that in this scenario, if 'Artists' was checked off, the files should be saved to: /Artists/<Artist>.m3u Note #2: -Whether the user chooses the entire library or a subset thereof, the selected .m3u playlists should be created. This will allow any 'dumb' device to behave almost like an iPod since users will be able to choose sets of tracks based on any number of criteria. If this is easy to implement, we should do so for MM 2.5 (it fits nicely with the data CD Burning functionality). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1025 | ||||
|
|
The simple implementation that is suggested above needs to be modified slightly since it assumes that the device will support subdirectories which isn't always the case. Generate .m3u Playlists for: [x] Library Playlists [ ] Genres [ ] Artists [ ] Albums . . Destination directory: _\Playlists\______________ . . [ ] Use subdirectories for generated Playlists OR, another possibly simpler approach: [x] Copy Playlists as .m3u files . . [x] Generate .m3u playlists for Artists, Albums, & Genres . . Destination directory: _\Playlists\______________ . . [x] Use subdirectories for all playlist types Notes: . . [x] Generate .m3u playlists for Artists, Albums, & Genres -->This would be similar to the current behaviour except that: -->a) it would apply to all all tracks (e.g. .m3u files would be generated for Genres if a Genre wasn't explicitly selected) -->b) it would create a subdirectory for Genres (\Playlists\Genres\...) -- this functionality currently isn't available . . [x] Use subdirectories for all playlist types -->This would cause sudirectories to be always used (i.e. for all playlist types) e.g. --> \Playlists\Artists\<Artist>.m3u --> \Playlists\Artists\<Artist>\<Album>.m3u --> \Playlists\Artists\<Genre>.m3u |
|
|
I think that the second, easier solution would be ok. What I think would be problem is the fact that playlist should have some prefixes to be useful. E.g. on H320 all playlists are shown to user as an order list. So, in order to make it useful, the result could look like: Artist-ABBA.m3u Genre-Pop.m3u Genre-Rock.m3u ... Question is, should we make it configurable (the prefix)? How? |
|
|
Assuming these are the only cases we have to worry about then: Change: . . [x] Use subdirectories for all playlist types To [x] Organize Playlists using ___________________^ [[subdirectory for each playlist type]; prefix for each playlist type] |
|
|
Per discussion with Jiri, we should go with: Generate .m3u Playlists for: [x] Library Playlists [ ] Genres [ ] Artists [ ] Albums [ ] Location . . Destination directory: _\Playlists\______________ . . [x] Organize Playlists using ___________________^ Also, here's a bit more of an explanation of the last option which could be configured in 3 different ways: 1) [ ] Organize Playlists using ___________________ (playlist files are just copied to the destination directory) 2) [x] Organize Playlists using __subdirectory for each playlist type__ (this is a dropdown option that creates directories as previously discussed in the bug) 3) [x] Organize Playlists using __prefix for each playlist type__ (this is a dropdown option that prefixes each playlist with the playlist type, in the manner described by Jiri). |
|
|
Pushing from MM 2.5.1. It's late in the release cycle and this should only be tackled once the CD Burning implementation (0002220) of this feature is implemented correctly. |
|
|
Resolved similar way as in case of burning (common M3U Settings dialog is used). Fixed in build 1006. |
|
|
Tested in build 1023 and .m3u playlists are not created for selected Library playlists, Artists, or Albums! |
|
|
You can enable m3u playlists creation by [x] Copy Playlists [Options...] but in case of some device plugins like d_iPod.dll this options are disabled by default. Jiri wanted me to make it this way, because m3u playlists on an iPod are not useful. So if you use an iPod to synchronize m3u you can't. We can change it, but discuss it with Jiri. If you used another device than an iPod it should work fine, because it works fine for me (I used a Flash disk with d_USBMass1.dll device plugin). |
|
|
Reopened, because according to the discussion with Jiri I did't know that this settings affect also creating of playlists in iPod DB too. So this iPod DB playlists was not created. This is fixed now. |
