how to attach local drive

[Giordano]

What update is what the "update library" does? Is it a full update or only the root of the drives?
Thanks,
JG

[Tim Curtis]

The "Update library" option runs MPD database update and the thumbnail image generator in parallel. MPD database update indexes everything. Same for the thumbnail generator which scans everything.

[Giordano]

   
I had a problem before, it did not want to scan the NAS share fully, only fraction of it. That is solved, not sure how, but works fine now.
Now, this problem came with the local drive. It has a small and a large folder and it does not scan the large folder. First, it did not scan the bigger folder at all, but I found the permissions were a problem.
Now, it starts to scan, but than it stops.
Even the larger folder disappears, or it remains, only a few folders shown.

Once I have captured an error message.

It says :MPD error, openMpdSock() failed

:-(

Regards,
JG

[Giordano]

I'm keep trying.
Did tried to remove and re attach, reboot etc. a few times. Now, it does not show up at all in the library.
I just tried to clear the log, update again. It starts to update fine, from the local drive, but at a point the logfile stops to grow, no errors, but it just stops and nothing is shown from the local drive. Nothing from what is in the log either.

It is very similar to what happened to me 2 days ago with the networks drive.
It looks like it is running out some kind of resources. Now I cleared again, it stops at the exact same point.

I have plenty of space on the sd cad for sure
pi@zeneM:~ $ df -h
Filesystem                     Size  Used Avail Use% Mounted on
/dev/root                       14G  2.9G   11G  22% /
devtmpfs                       895M     0  895M   0% /dev
tmpfs                          927M     0  927M   0% /dev/shm
tmpfs                          927M  9.4M  918M   2% /run
tmpfs                          5.0M  4.0K  5.0M   1% /run/lock
tmpfs                          927M     0  927M   0% /sys/fs/cgroup
/dev/mmcblk0p1                 253M   55M  198M  22% /boot
/dev/sda1                      3.6T  3.1T  405G  89% /media/zeneM
//192.168.2.21/zene            5.5T  2.7T  2.8T  49% /mnt/NAS/zene
//192.168.2.21/ellenorizetlen  5.5T  2.7T  2.8T  49% /mnt/NAS/ellenorizetlen
tmpfs                          186M     0  186M   0% /run/user/1000

I give up for now, have to sleep some :-)

Regards,
JG

[Cardone]

Good morning Giordano,
if something doesn't work as you wish, many hours are spent without eating and without sleep ..
We will find out why the HDD is not displayed on you.

Which MoOde version do you have installed?
Have you tried FAT32 with a USB stick?
Have you tried a 2nd SD card (new installation)?

Don't forget that you have to update the update library !!


Ciao alla prossima
Zeferino

[jonners]

I had a somewhat similar problem recently and it was solved by a fresh install of Moode.

[Giordano]

Hi Cardone,

I did installed the latest version, 6.7.1 I believe. A few days ago, when I had the similar problem with the network drive, I have tried to install to SD with win32 disk imager, with dd, with balnea etcher also. I found no difference. Than, I've installed the same to anorter SD card and suddenly everything started to work. The network drive is fully scanned.

Now, I have the same problem, but with the local drive. Again, when I clean the mpd log, it stops at the same file. Now the log is not 1M long, only 700k. If I remove the album where it stops, than it stop at the next one.

I did not try FAT32, only ext4. I could try NTFS also, but I do not really like NTFS under a linux kernel. For test, I can do. It takes 1.5 days to copy, that is the only problem.

I did not try a new installation again, but I will now.

I'm also thinking that I'm not expanding the file system at all.

To me, it really looks like I'm running out some kind of resources.
Isn't it possible that tmps runs out of space?

Thanks!!
JG

[TheOldPresbyope]

Hi Cardone,
...
Now, I have the same problem, but with the local drive. Again, when I clean the mpd log, it stops at the same file. Now the log is not 1M long, only 700k. If I remove the album where it stops, than it stop at the next one.
...
Thanks!!
JG

This behavior suggests to me that your problem is not with configuration or format but with content. The scanning is done by MPD and MPD is notoriously closed-mouthed about what it doesn't like about a file---notably its metadata.

You might have a look at the section "MPD hangs on first startup" (not a great title) in this article

https://wiki.archlinux.org/index.php/Mus...leshooting

If you're seeing this problem album after album it's likely there's a common issue among them. Zip up one or two, push the the zip file to some file sharing site and PM the link to me and I'll have a look.

I could be wrong, of course, but if I'm right then everything else you are doing is just busy work.

Regards,
Kent

[Giordano]

Hi,
I did tried to delete the ones and after the one where it stops. Than it stops at the next one.

Also, the 2016 moOde is using the same shares fine. The share and the attached drive content is the same.

At the system config, it says "System logs". So, it is not just the mpd log as I read it. What other logs we have?

I found a /var/log/moode.log. Did found error in it also:
***
...
20200907 170746 watchdog: PHP session permissions (reapplied)
20200907 170752 watchdog: PHP session permissions (reapplied)
20200907 170752 watchdog: MPD restarted (check syslog for errors)
20200907 170753 engine-mpd: Connection to MPD failed
20200907 170753 moode.php: MPD connect failed: cmd=(playlist)
20200907 170753 worker: Job update_library done
...
***
In syslog I find this :
***
Sep  7 17:16:01 zeneM nmbd[515]: [2020/09/07 17:16:01.046377,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
Sep  7 17:16:01 zeneM nmbd[515]:   query_name_response: Multiple (2) responses received for a query on subnet 192.168.2.9 for name WORKGROUP<1d>.
Sep  7 17:16:01 zeneM nmbd[515]:   This response was from IP 192.168.2.8, reporting an IP address of 192.168.2.8.
Sep  7 17:16:01 zeneM nmbd[515]: [2020/09/07 17:16:01.046744,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
Sep  7 17:16:01 zeneM nmbd[515]:   query_name_response: Multiple (2) responses received for a query on subnet 192.168.2.10 for name WORKGROUP<1d>.
Sep  7 17:16:01 zeneM nmbd[515]:   This response was from IP 192.168.2.8, reporting an IP address of 192.168.2.8.
Sep  7 17:18:00 zeneM systemd[1]: Started Session c3 of user pi.
***
192.168.2.8 is a libreElec player, named differently, but under "WORKGROUP". Anyway, it does not seem to be connected.

I did repeated it now, but now I was watching the % useage of the mounts, especially tmpfs. There is not a single single digit change, it is far away from being full.

I do not know. At the eveining, I will try a fresh flashing to the sdcard.

Are there other logs to watch?

Regards,
JG

[TheOldPresbyope]

@Giordano

It occurs to me that we still haven't seen any information about the system we're talking about. How about posting the System Information output?

I also haven't seen any mention of the power supply situation. Is the USB drive connected directly or via a powered USB hub? A hard drive can demand large currents during some disk operations and cause transient mis-behavior of the system if it's being powered via the RPi USB port. 

The only local drive I use is a small-ish (120GB) SSD which works ok directly connected to an RPi4B with a 3a/5v power supply and short cables everywhere but larger drives and particularly HDDs are suspect.

Regards,
Kent