View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009585 | MMA | General | public | 2012-08-17 03:04 | 2012-12-08 23:24 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 1.0.1 | Fixed in Version | 1.0.1 | ||
| Summary | 0009585: Database fails to update on new/deleted tracks/playlists | ||||
| Description | If the android device is being managed by other apps in addition to MM, there needs to be a way for MediaMonkey to rescan the device. I suggest that this should be done via: Settings > General: Rescan the device for media files OR Can this just be automatically done every x hours? | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 60 | ||||
| related to | 0009590 | closed | marek | Attempting to play a track that doesn't exist triggers device reboot |
| related to | 0009575 | closed | martin | Album Art is missing for many tracks after initial scan |
| has duplicate | 0009723 | closed | marek | MM doesn't update while Media Store is being updated |
| related to | 0009768 | closed | marek | MM scans too often / too long |
|
|
We read metadata from Android Media Store and keep them always updated (in both directions). I.e., we cooperate nicely with any _properly_ implemented application and so this feature isn't needed. When we sometimes later implement direct tag reading in MMA, something like this might be useful. |
|
|
I'm not sure I understand. If I manually copy/delete music to the device, MM's DB doesn't update right away. Can you elaborate? In fact, it triggered bug 0009590 (note, though, that after bug 0009590 occurred, and my device restarted, the deleted track was no longer in the MMA DB). |
|
|
How do you copy the file, using MTP? If the file appears in the internal Music application right away, it's supposed to appear in MM as well. In case it doesn't, it's a bug that should be assigned to Marek. |
|
|
I triggered this bug by removing tracks via Windows Explorer (i.e. as a USB MS device) or via a file manager on the Phone. What I notice is that MM initially shows the removed tracks, then the hourglass appears in the list view of the tracks (but the removed track remains), and only when I go up a level and then go back to the view (in order to trigger a refresh) does the track get removed. So it seems that the view isn't getting updated even though the Android file system DB is. |
|
|
Here's exactly what I do: 1) Sync tracks to MMA via MM (device is a Nexus 7 runing JB or Xperia Pro with GB) 2) Disconnect 3) Reconnect (note MMA is still running) 4) Open windows Explorer, navigate to My Computer > Nexus > Internal > Music > Artist > Track 5) Delete the track in Windows Explorer 6) Disconnnect the device 7) In MMA, go to the main menu and back to Artists menu (in an attempt to trigger a refresh) --> Artist still displays 8) Click the Artist --> The track still displays 9) Play the track --> MMA crashes |
|
|
Rusty, and steps 7-8 work well in other applications? As discussed over IM, Marek will check out whether step 9 is already fixed. |
|
|
Tested 7-8 on different platforms apps: 1) Nexus 7 (Jellybean - MTP mode) - Google Music: correctly recognizes the change - Winamp: correctly recognizes the change (in fact, it'll dynamically register the change to the view. e.g. If in Artists view, and the only track by Bob Dylan is removed, then 'Bob Dylan' disappears from the view). - MediaMonkey: doesn't recognize the change 2) Xperia Pro (Gingerbread - USB MS mode) Results are not 100% consistent. - MediaMonkey: never recognizes the change - Google Music: usually, but not always recognizes the change (on a couple of occasions it didn't). The interesting thing is that in USB mode, after attempting to view the deleted track in Google Music and then running MediaMonkey, then MediaMonkey usually recognized the change--this is very similar to 0009575 (where MM fails to detect Album Art, but then detects the art after Google Music is run). p.s. in the latest builds of MM, I've seen the following behavior. - Deleted track displays - Attempts to play it cause another track to play - A minute later, upon refreshing the browser list, the deleted track doesn't display |
|
|
Note: another means of triggering this is to sync an auto playlist with MMW that randomly changes on each sync, and have tracks auto-delete if they're not on the sync list. --> many tracks are deleted from the device, but on browsing the device, all those tracks remain in MMA. --> videos and podcasts that were synced did not appear in MMA. The only way to get them to appear was to 'Stop' MMA via Android apps panel, and Delete data/cache. Then when MM restarted, all of the new videos appeared (podcasts and audiobooks did not appear). |
|
|
Note: in addition to tracks, Playlists also fail to update. |
|
|
Resolving, since I'm unable to reproduce. I wonder whether it isn't caused by playlist scanning problems that caused media scanning to be unrelible -> which could result in very late scanning of new media by MM. This is fixed now, so hopefully it also resolves this issue. |
|
|
Tested build 32 with Nexus7(jellybean) and the bug still occurs (based on repro steps described at http://www.ventismedia.com/mantis/view.php?id=9585#c31763), but doesn't occur when using the stock Music app. Note also: -I waited for a minute following deletion of the track using Win Explorer however, the track was not removed from the view (even on refresh), and the crash on attempted play still occurs. In contrast, the stock Android Music App removes deleted tracks within seconds. -The bug occurs for tracks that are added individually OR tracks that are added because they're part of a playlist. |
|
|
Well the problem is that the default Music app uses MediaStore DB directly. And MTP works also directly with this DB. So when files are modified this way (MTP), Media scanner is not ran. And we are able to catch media scanner events only. I will try to figure out if there is a way how to handle this situation. |
|
|
Fixed in build 36 Implemented using recursive file observer on whole filesystem (i.e. many inotify instances). This might be very memory-consuming. |
|
|
Build 37: - We have run into this issue on Galaxy S2 - this is currently failing to pick up new songs, and is in a continuous "updating" state. Attached a log, although not sure it is useful - We have also found Sony Xperia Arc will only get the new song when the app is forced shut and restarted Please let me know if there is any additional information you require. |
|
|
Resolving, since these issues should already be fixed. Please reopen in case it isn't so. |
|
|
Tested build 40. The problem seems to be solved (tested in GB device), however, the cost in terms of performance and memory utilization isn't acceptable: - it takes over 5m to scan 1000 tracks - memory utilization of MediaMonkey after the scan is > 21MB |
|
|
Some related issues fixed, assigning to Rusty to suggest an UI for start of manual scanning - which is needed since we can't guarantee 100% that everything will be picked up manually. |
|
|
my understanding of the status is that the fix works (changes are detected), and that the only problem is that performance isn't that great (it can sometimes take awhile to detect that a track was deleted). I'm having trouble understanding: a) why does the google Music app 'know' right away if a track has been deleted (in contrast to MMA which can take some time) ? b) what failure is prompting you to indicate that you want a manual trigger to initiate a scan ? note: if we decide that we need a manual rescan, we can use: Settings > General: Scan device: Updates the database regarding new / deleted media files |
|
|
We modified the monitoring routines in build 42, since they were too resource consuming. That said, Marek is currently working on another improvement, which will probably remove the necessity for a manual scan. To reply: a) They work directly with the internal Android Media Store. We have our own DB. That said, we are trying to get better notifications from MS... b) Hopefully none after the fix. Assigning to Marek to resolve in case of a successful fix or implement the manual scan in case it will be needed. |
|
|
Fixed in build 43 |
|
|
Tested build 43 for updates based on addition / deletion: - Xperia Pro (GB) in USB MS mode: functions as expected - Nexus 7 (JB) MTP mode: MMA does not update the DB to reflect file deletion/addition |
|
|
Fixed in build 44 |
|
|
Verified build 44. |
|
|
MMA now cannot handle properly playback of playlist when some/all of tracklist's tracks are deleted. |
|
|
Fix in build 57. |
|
|
Tested build 59 as follows: Synced 2 playlists and deleted tracks that weren't on sync list: --> Nexus 7 (JB 4.2): List views show old content / old playlists (new ones don't display) + Scanning indicator never goes away xperia Pro (GB 2.3.4): Same as above + crash. On reboot, new content displays. |
|
|
Fixed in build 60 |
|
|
Verified 75 |
