m4a plugin breaks library scanning

[mixxxbot]

Reported by: bkgood Date: 2010-11-16T21:03:48Z Status: Invalid Importance: Medium Launchpad Issue: lp676247 Tags: library, m4a, mp4, scan

---

(This is the short version because I clicked a link on the report bug page thinking it was AJAX and then lost all the nice things I wrote, thanks LP :) )

After scanning m4a/mp4 files for a while, library scanner starts spewing debug info:
Debug: [LibraryScanner 1]: Couldn't mark track "/home/jason/Music/Britney Spears/_..Baby One More Time/10 E-Mail My 
Heart.m4a"  as verified. QSqlError(14, "Unable to fetch row", "unable to open database file") 
Debug: [LibraryScanner 1]: Getting SoundSource plugin object for "m4a" 
Debug: [LibraryScanner 1]: Decoder Config 2 44100 0 0 
Debug: [LibraryScanner 1]: MP4Read failed 
Debug: [LibraryScanner 1]: SSM4A::initializeDecoder failed "/home/jason/Music/Britney Spears/_..Baby One More Time/10 E-Mail My Heart.m4a"  with status: -4 
Debug: [LibraryScanner 1]: SELECT hash failed: QSqlError(14, "Unable to fetch row", "unable to open database file") 
Debug: [LibraryScanner 1]: Creating new dirhash failed: QSqlError(14, "Unable to fetch row", "unable to open database file") 

Mixxx is being starved of available file descriptors (probably by some libc policy enforcement) because SSM4A::parseHeader calls MP4Read on a file (opening the file) but never closes it with MP4Close, thus we run out of file descriptors, can't open another mp4 file ("MP4Read failed"), and can't open the sqlite database for writing. In the end, mixxx finishes scanning and you get a subset of your m4a files in the library.

[mixxxbot]

Commented by: bkgood Date: 2010-11-16T21:32:25Z

---

Fixed in 1.8 r2670, trunk not affected since it uses TagLib in SSM4A::parseHeader.

[mixxxbot]

Commented by: bkgood Date: 2010-11-16T21:48:49Z

---

Only partially related to this, the m4a plugin now runs cleanly in valgrind (or does as far as I've seen).

[mixxxbot]

Issue closed with status Invalid.