[PROBLEM] library update in progress

[philrandal]

Many thanks to all!

@philrandal
Exact mounting parameters are standard vers=1.0,ro,dir_mode=0777,file_mode=0777. I have changed vers to 2.0, 2.1 and 3.0 with the same result, maybe 2.1 was a little faster. I have used 2 versions of MPD and 64-bit kernel too, the problem of library update stays unsolved. I still use W7 because this PC is not for work, for storing media only.

I've had issues with vers=1.0 in my setup.  It's best to use 2.0 or above where possible.
Some of the other mount parameters such as cache and rsize might / might not benefit from tweaking.
Phil

[arick]

Just an aside: 30,000 albums is about 60 years of collecting 10 albums a week.

Hardly a normal use case :-o

(Not that I'm envious or anything LOL)

Just an aside: it is about 8TB, you can collect it for a month or two easy except something rare.  I listen to a lot of music. Jazz, classic, rock, blues, world, all except metal and rap. Normally it is about 5-10% of collection, but I’m not using streaming services and have all what I may to need. I don’t spend the time for collecting of the music.

[swizzle]

@swizzle
It will take several minutes to replicate the problem by Tim. It’s necessary to write the image and to start library update, it’s all.

I think it‘s developer problem of incorrect library generate or update ending. The system jobs are ended normally, but some system triggers doesn’t indicate it, even after rebooting.

It’s almost certainly an mpd issue but to replicate if you need the entire system and not just the image.

[arick]

It’s almost certainly an mpd issue but to replicate if you need the entire system and not just the image.

You don’t need the entire system. You can run the image on any RPI 3b+ without music sources, and the library will not be able to be updated to empty, I have tested and wrote about it in #15.
Meanwhile, I think I found the source of my problem. I need some time to check this version, but I’ll not be able to solve this problem without modification of source code.

[arick]

So, I think it is developer bug and it is not connected with the library size.
When I initiate folder update from folder context menu (to update MPD database only for the single folder), the system also automatically runs thumbnails update for the WHOLE music library. The MPD database update ends very fast for separate folder and update indicator on the screen disappears. But the thumbnails update is continued (in my case for a long time). If something will happened while that time (RPI reboot or shutdown, disconnect with music source, dismounting music source etc) the whole library became corrupted and not updatable.   Here is the fragment of log confirming my version. We can see that thumbnails were updated with whole scanning all the sources.
 

Code:

20200717 074307 worker: Watchdog started
20200717 074307 worker: Ready
20200717 094303 worker: Job update_library
20200717 094304 thmcache: Start
20200717 094304 thmcache: Scanning: NAS, SDCARD, UPNP
20200717 094334 worker: Job update_library done
20200717 101346 thmcache: mp3: /var/lib/mpd/music/NAS/Rock/Radiohead/Singles/2011 - Supercollider-The Butcher/2 The Butcher.mp3
20200717 101346 thmcache: mp3: Zend media exception: File does not contain ID3v2 tag of supported version: v2.2
20200717 101455 thmcache: Done: 28919 album dirs processed

Can anybody else check this and signalize to Tim? Sadly, Tim has leaved this thread. I think it is very easy to solve this problem by sending the folder name to thumbnail update job.

PS When the thumbnails were updated normally I run folder update again. But I have seen “library update in progress”, the library became corrupted  ((
But I’m sure that the problem is arising only when the single folder is updated

[arick]

It’s almost certainly an mpd issue but to replicate if you need the entire system and not just the image.

It is not an mpd issue. Just restored SD and done exactly the same updates that in #35 directly via SSH by mpc update command. All updates were well and fast done. And the library still updatable. So, it’s almost certainly an moOde issue )

[TheOldPresbyope]

Hate to spoil your argument, but

Code:

20200717 101346 thmcache: mp3: Zend media exception: File does not contain ID3v2 tag of supported version: v2.2

means what it says. The file in question doesn't contain a supported version of ID3 metadata. Nothing to do with moOde and certainly nothing to do with your issue. I have a number of test files in my system which produce the same message.

the system also automatically runs thumbnails update for the WHOLE music library.

Yes and this update runs fast on an system with reasonable file access times.

Regards,
Kent

[arick]

Hate to spoil your argument, but

Code:

20200717 101346 thmcache: mp3: Zend media exception: File does not contain ID3v2 tag of supported version: v2.2

means what it says. The file in question doesn't contain a supported version of ID3 metadata. Nothing to do with moOde and certainly nothing to do with your issue. I have a number of test files in my system which produce the same message.

the system also automatically runs thumbnails update for the WHOLE music library.

Yes and this update runs fast on an system with reasonable file access times.

Regards,
Kent

Dear Kent,
The file with unsupported tags couldn’t cause the update problem. This file existed when library was initially generated and was successfully parsed. It is in the library now.
 

Code:

Supercollider 07:02
Radiohead - Supercollider / The Butcher
The Butcher 04:41
Radiohead - Supercollider / The Butcher

If you don’t believe, I can delete this file and repeat all procedures for two days. Do you think it helps to solve my problem?

As to thumbnails update, is it necessary to update all thumbnails when the single folder was changed? Is it really necessary? Is it so difficult to set the correct parameters for thumbnails update procedure?
Regards