[parse.c:1078] error: Giving up searching valid MPEG header

Hi, I am not sure if VolumIO on my RPi is working or not. My problem occurs at the stage where the program tries to populate the library. I am trying to access around 40GB of music files in a mixture of format over a CIFS/SMB share. It connects and begins to populate, as shown by the log. The log includes quite a few “added NAS/…” entries, then nothing but the error message “[parse.c:1078] error: Giving up searching valid MPEG header after 65536 bytes of junk.”. Tail -f of the log file shows that it is still running, adding a new line like the above every minute or so.

Is there any hope that VolumIO is actually building the database, or has it got confused somewhere along the line? Can you suggest a graceful way to back out of the database-building process and start over?

Thanks in advance for any assistance.

Dean

Update: I restarted the MPD service and clicked on the button in the Settings menu to update the database. It stalled with the same message after the exact same file. It completes 41 files in this folder (which contains 155) then just spits the error message. That would suggest there is a file it doesn’t like in there, but it appears to be either unable to process any more files or continually trying the same file.

Update2: I removed the folder containing the offending file from my music folder and restarted the database and it got past the point it got stuck before, but eventually the same problem occurred in a different folder. This is no doubt a problem with my music files, which have been moved from machine to machine and restored from an iPod at least once. However, …

Might I suggest that you try to add each file, if unsuccessful then give up and move on to the next one? I also strongly suggest you log the file name giving the problem in the log file. If that is not possible with the current process flow, it would be more useful if the log showed which file it is trying to add before trying, rather than showing which file was just successfully added, since I have no way of knowing which file it tried next.

This is a problem of ffmpeg

edit /etc/mpd.conf

and remove this

decoder { plugin "ffmpeg" enabled "no" }

Then update db again, let me know

I inserted # signs in front of the relevant lines, which I expect would have the same effect as deleting them. There is no change, the process of populating the database stalls at the exact same spot. I don’t know if parse.c is part of ffmpeg or your package.

I’m not in an urgent rush, but I’d like to get this working. I think it would be best for both of us (my assumption!) if you could fix the logging so it was useful, then I could provide more useful information. I hope I don’t sound demanding, I am honestly hoping to make this better for everyone. I’m excited about the potential.

Best regards.
Deam

Could it be related to the version of mpd that is being used?
Is there a simple way to update mpd to version 0.17.0 (released june 2012) and the current version 0.18.7 (released a few days ago)?

Might be worth to try it out, my library also isn’t being built due to that same error.

Someone knows how to update mpd using an “instable” package?

TIA

daf art

Hi there,

I ran into a similar problem, and AFAIK it is related to the CIFS share.

Indeed, I had a CIFS share and got the same message than yours. Since it was on Linux, I remounted it using NFS and the error disappeared. My library was correctly scanned.

I didn’t try to find out where the error would stem from, but I think if you have to stick to CIFS/Samba, you shoud try to search for mount options and/or file encoding.

Hope it helps.

Cheers,
Jdif

Hi jdiff, thanks for the suggestion. I think you might be right, as Amarok has no problem reading the entire collection on the server.

I’ve traditionally struggled with NFS on my home network for some reason, but this was motivation enough to try again, especially as I’m Windows-free now. I can configure the share (sharing /home/username) and mount it from an ssh session (logged in as root) with

mount -t nfs -o proto=tcp,port=2049 192.168.0.10:/ /mnt

but I can’t seem to figure out the right combination of entries into the various fields of the Edit Network Mount page to get volumio to do the same thing – it gets stuck with the spinning “Connecting” logo. I did put the flags from the above command into the Advanced Options > Mount Flags box.

If you or anyone else can get me through this last hurdle I think I’ll have it licked.

Hi,

Since you can manually mount your share in command line, there should be no trouble doing it with the GUI.

I’m pretty sure it is about filling the lines in the right order :slight_smile:

Mine was mounted easily without specifying any specific parameters.

Be sure to point to the share correctly in Volumio (IP address : 192.168.0.xx ; Remote directory : /my/share/in/absolute/path)

Or if you want to do it manually, you could also mount your NFS share to /mnt/NAS (via /etc/fstab) and Volumio should be able to see it without the need to configure it from the WebUI.

Eventually, try to get some log files and to debug the mounting problem directly in the pi (via ssh)
Some tips that might help : tldp.org/HOWTO/NFS-HOWTO/tro … oting.html

Cheers,
jdif

Hi,
the problem still exists.
" Giving up searching valid MPEG header after 65536 bytes of junk."
not all the content of the NAS is shown in the libary.

RuneAudio does the update correct and shows all my music.
Currently I am testing Volumio and Runeaudio in parallel.
I prefer Volumio because I dont like archlinux.

But some problems with Volumio have to be solved :wink:
MeiT