[SOLVED] Mopidy local scan: Segmentation fault

General
1

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
Segmentation fault

I’m running mopidy 2.0.1 on the latest raspbian an a raspberry pi 1 model B.

My config:

[local]
enabled = true
library = images
media_dir = /var/lib/mopidy/media
scan_timeout = 3000
scan_flush_threshold = 100
scan_follow_symlinks = false
excluded_file_extensions =
  .directory
  .html
  .jpeg
  .jpg
  .log
  .nfo
  .png
  .txt

[local-images]
enabled = true
library = json
base_uri = /images/
image_dir =
album_art_files =
  *.jpg
  *.jpeg
  *.png

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!

2

Info on logging (and gstreamer logging) is at https://docs.mopidy.com/en/latest/troubleshooting

3

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.

4

Have you tried using the sqlite local backend? How did you conclude it’s not in gstreamer?

5

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.

6

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.

7

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?