USB HDD brings mopidy's webclient down

Pi MusicBox
1

Today I’ve been testing a new 2.5" USB3 HDD enclosure I got from Amazon, and after formatting a known working HDD and sticking it to musicbox with some files, it doesn’t seem to like it at all. After some seconds having plugged it in and browsing its subdirectories, it simply makes the webclient spit “trying to reach musicbox” for a while, then it simply brings it down into ECONNREFUSED. I’ve tried increasing current in config.txt with max_usb_current=1, formatting the drive in FAT32 or NTFS, re-scanned my music library (i had that feature turned off because it would make the boot much slower), and rebooting mopidy from ssh after it crashes, to no avail.

I’m using a 5V2A power supply and everything works perfectly fine with a different drive, 2TB USB3 HDD, which was NTFS formatted. What prompts me to think it’s a bug is that despite the webclient dying out, I can ssh to musicbox and ls my way through the filesystem, and also get metadata from the music files using the file command. So it’s not giving up or having problems on reading the drive itself, it just for some reason crashes the browser.

I haven’t included a log because in /tmp/mopidy-debug.log I only see dumps of the library being scanned, no crash or anything despite it crashing the web client.

If I can do something to better debug this problem I will provide any logs that actually provide useful information into here.

2

What exactly are you doing in the webclient to trigger this behaviour?

What model raspberry pi is this?

Have you moved the music database file from its normal location on the SD card to the hdd? I ask this because normally once the music files are scanned the mopidy-local plugin has no direct interaction with the music files when navigating/searching the library, only actually playing the files will read the drive.

The http server may struggle to accept webclient requests when the system as a whole is very busy. If it actually ‘crashes’ or fatally errors the http server then you should always see an exception in the log file but I can’t see why that would happen. Even if the system was heavily loaded and a webclient connection couldn’t be accepted, once the system load dropped I would expect it to start working again and certainly once mopidy was restarted. After you’ve finished scanning the music collection (either at boot or manually), there should be no other scanner log messages if you are using mopidy-local. Trying to use the system while it’s scanning is not going to be fun.

Mopidy-file is a different beast to mopidy-local and that could cause the problems you describe depending how the music files are organised (very many files in directories will not perform well) and depending on what raspberry pi you have.

3

Simply by turning on the pi, waiting for a while so the webclient boots up (if library scanning was enabled, i wait until the led on the hdd enclosure stops flashing, which is when i assume it’s done doing its on-boot library scanning) and browisng through the hard drive’s files using the webclient. Regardless of filesystem or power supply used, it simply happens.
That’s all it takes with this particular HDD and HDD enclosure to bring it down. It drops ECONNREFUSED around the third or so subdirectory, while just clicking on the very first directory (my hdd’s folders are /music/USB-HDD/music/folder1/file.mp3 , in the bold subdirectory it’s when it crashes, it does take a while and I have to refresh the page so i can see the ECONNREFUSED though).

I’m planning to try a different 2.5 HDD to pin down if the issue is compatibility with the enclosure itself or the hard drive. Would be a great letdown if I can’t get this one to work, since I bought it to use it here.

Its a raspberry pi 2 model b+ v1.1 (as it says on the pcb)

I’ve tampered nothing at all with the settings or the SD card itself, besides reflashing the musicbox img wondering if it was corrupted or something. Also tried enabling library scanning on boot just to see if the crash was due to a lack of sync with the just-installed hard drive (i had the library data of the previous 2T one, although they had the same files, i was weary of it maybe conflicting in some way).

So far nothing worked. What I had time to do today is swap the HDD off that enclosure into a 3.5" one that had an independent power supply (trying to track down a power issue here). Same result.

I’ll edit this to report if changing the hard drive in the enclosure had any effect but I doubt it.

4

Exactly what browsing are you doing i.e. Browse -> Files or Browse -> Local Media ?

Can you please provide /tmp/mopidy-debug.log

How many files are in /music/USB-HDD/music/folder1 ?

5

Here’s what I’ve just done:

I’ve chkdsk’d the offending hard drive (currently FAT32 formatted using gparted) to make sure the filesystem had no problems on a Windows machine, then when it was done I’ve shut it down gracefully. Then I’ve cleared the log file, plugged in the hard drive and turned on the musicbox. After waiting enough so that it would boot (with library scanning enabled, it oddly didn’t scan for the files) Then I’ve went into Browse -> Files -> USB (wasn’t in USB-HDD atm for some reason). This is what happened after entering the one folder containing the music inside the HDD’s root (it happens right after entering it, and there are like, maybe 60 or 70 folders and some files in it, don’t know how to count them using the terminal over ssh):

image
image.png1444×603 39.7 KB

If i simply wait for it to reach, it goes back one directory (the root) while in the first music folder inside the root, i can still browse one more folder. Then, it won’t take it anymore and drop into ECONNREFUSED.

image
image.png854×623 24.1 KB

I can still ssh and browse the filsystem within this just fine, so I’m gonna cp the log file into /music, then grab it from SMB and post it here. whew

One more thing: while trying to browse the offending folders that eventually bring down the web client, the system doesn’t show up anything unusual when running htop over SSH to check resource usage (at most, i get 3% CPU usage in one core, not even 80MB of RAM in use) so it doesn’t seem like an overload problem either.

Also, after a while the webclient does restart and it works without me having to bring the machine down (this problem still being present). Although I think it takes less time to simply reboot it using this switch I have on the USB cable…

Edit: I’ve found that it seems to happen in MPD as well (i’ve tried using ncmpcpp instead of mopidy’s webclient just to see if i could get some music working but same result, after browsing into the music collection itself blurts an instant connection refused). I have been using ncmpcpp + mpd + mpdas on my main PC running debian and had no issues whatsoever with this same collection (albeit in a different hard drive, but thats that).

Edit 2: Success!.. using standard mpd. after making an audio output for the headphone jack and copying this edited mpd.conf to the home directory of the user, then running mpd and ncmpcpp, the hard drive works perfectly fine! sadly i don’t get any of the nice features of mopidy’s webclient like those nice radio streams and scrobbling (mpdas didn’t want to compile on the pi for some odd reason). both mopidy and mpd+ncmpcpp seem to work just fine! as long as I switch back and forth. But at least I’ve got some way of using my hard drive as intended until we have a fix with mopidy. :slight_smile:

I hope this testing was useful.

Thanks again for this system I really love it. And for your support.

6

I fixed my issues, turns out there were some files in the root folder where all the music files and folders were that were either corrupted or in bad shape, and they were crashing the webclient. After deleting those it works perfectly! :joy: i feel like an idiot.