View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005224 | MMW v4 | DB/FileMonitor | public | 2009-01-20 15:27 | 2014-08-18 14:46 |
| Reporter | rusty | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Product Version | 3.1 | ||||
| Target Version | 4.1.5 | ||||
| Summary | 0005224: Scanning .m3u files fails to update the DB properly | ||||
| Description | 1 'Add/Rescan Tracks to the Library' with M3U ticked fails to rescan M3Us i.e. to update changed playlists already in 'Imported m3u playlists', or to restore references to deleted and restored tracks in same, or (most seriously) to restore playlists deleted from 'Imported m3u playlists'. A workaround is to first delete the Imported m3u playlists node - unfortunately this necessarily loses any playlists that have no reimportable copies. I suppose that we'd need a timestamp associated with the .m3u playlist nodes in order for this to work correctly. 2 'Add/Rescan Tracks to the Library' fails to update the presence/absense of the 'Imported m3u playlists' [+] icon. Possibly related are: Note: MM3 change log: 2786 Fixed newly added/converted tracks fail to trigger a refresh of the current view Note: 0021 Fixed empty tree nodes should not have a '+' | ||||
| Steps To Reproduce | Reported by chrisjj at: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=15610&p=78121&hilit=refresh#p78121 | ||||
| Additional Information | Reported at: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=15610 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
1. I don't think this is possible. User could have already edited the playlist in Library and so after any rescan from M3U these changes would be lost. That's quite a general problem of synchronization and it isn't clear which one should win (latest timestamp doesn't seem to be enough). I think that the current functionality is ok, the point is to get m3us to Library so that user can easily work with them. Any possible further operations (like re-reading them, maybe writing changes from Library back to m3us or anything else) can be implemented using scripts. |
|
|
This issue is pretty similar to 0001502. Since we've decided to go with the more recent set of changes for Files in 0001502, we should do the same for playlists here. Push if too risky at this stage. |
|
|
I think that this could only be possible to implement the suggested way in case we write any change to a playlist in MM to its M3U pair in filesystem. It's generally speaking possible, but if we implement this, we also should give user a chance to edit which m3u playlist is linked to given MM playlist. I.e. there isn't a trivial solution, deferring. |
|
|
http://www.mediamonkey.com/forum/viewtopic.php?f=1&t=76949 Can you look at this it shouldn't be hard to add? |
|
|
2. Will be fixed as a part of reworked MM5 UI and backend. |
|
|
The objections seem inapplicable to: > (most seriously) to restore playlists deleted from 'Imported m3u playlists'. > A workaround is to first delete the Imported m3u playlists node - > unfortunately this necessarily loses any playlists that have no > reimportable copies. which remains unfixed five years after report. Could this case me made a separate issue? |
