When I execute
sudo mopidyctl local scan then I get this error:
(python:9966): GStreamer-WARNING **: tag 'ID3v2 frame' should hold value of type 'GstSample', but value of type '(null)' passed
I’m running mopidy 2.0.1 on the latest raspbian an a raspberry pi 1 model B.
enabled = true
library = images
media_dir = /var/lib/mopidy/media
scan_timeout = 3000
scan_flush_threshold = 100
scan_follow_symlinks = false
enabled = true
library = json
base_uri = /images/
My collection consists of several file types: mp3, ogg, flac and sadly some wma’s. The files are completely on a locally mounted CIFS share. The read permissions are alright.
(btw. #465 is not the cause)
How can I debug that situation any further? Are there CLI switches to turn on verbose logging?
Thanks in advance!
After more investigation it turns out this has nothing to do with gstreamer. I found out that the
local scan command seems to have a memory leak which blows out my Raspi 1 Model A ram (256MB) after some time. The process memory usage is constantly growing during the scan process. After a certain amount of time/scanned tracks the system seems to become unable to do anything due to the missing free ram.
Have you tried using the sqlite local backend? How did you conclude it’s not in gstreamer?
The sqlite local backend has recently dropped the feature to browse by folders which is crucial for me.
I’ve tried several times and had different results:
- different music tracks when the process aborted
- different error messages
- I extended the swap file and then it has worked
So conclusion is there isn’t a memory leak. The scan process only needs enough ram proportional to the music collection size: In my case this is sightly more than my raspi has got.
The json backend is more of a proof of concept and loads everything into memory before writing our the library file all in go. The
scan_flush_threshold config is not supported. It won’t see any updates and there are plans to remove it in favour of mopidy-local-sqlite. If you want to browse your filesystem hierarchy, use Mopidy’s file backend.
If it’s going to be removed or abandoned that would be a blocker to me. My music collection consists of many tracks which are not part of an album but collected by other criteria in folders.
Mopidy’s file backend also isn’t a good alternative as it reads all metadata on demand which takes a lot of time when adding many tracks at once to the playlist. This leads to bad responsiveness at the client resp. timeouts when using an mpd client. I would love to see the feature “browse by directory/folder structure” back in mopidy-local-sqlite @tkem @jodal ! Maybe I can help to reintroduce it somehow?