Seeing what's happening in library updates

[MooicIan]

I have two Pis with moOde here, both running 8.0.1 2022-03-17. Both are using a miniPC running Windows for their library, over SMB. Both have the same settings for that and both have the green tick on the library source.

I recently added more tracks to the directory there.

One Pi can see them, after updating the library. The other is having problems - it's much slower to update and then can't see the changes.

It's currently regenerating the library to see if that works.

Is there a way to see the library being generated / updated when logged in via ssh? "Found directory 'Wombles', found album 'Greatest Hits', found track 'Hall of the Mountain Womble', adding track 'Hall of the Mountain Womble', found track 'I Hate Tobermory', track 'I Hate Tobermory' already in library, etc.."?

[TheOldPresbyope]

@MooicIan

Try

tail -f /var/log/mpd/log

You'll see a stream of lines in the log as MPD processes the contents of its music directory.

Example

Code:

pi@m81pi3a64:~ $ tail -f /var/log/mpd/log
Jul 23 06:34 : update: updating NAS/OMV-Music/NewAge/William Ackerman/In Search of the Turtles Navel/02 William Ackerman - Ely.flac
Jul 23 06:34 : update: updating NAS/OMV-Music/NewAge/William Ackerman/In Search of the Turtles Navel/01 William Ackerman - The Pink Chiffon Tricycle Queen.flac
...

You may see 'added', 'updating', 'removing' lines depending on what MPD finds.

Note that this command continuously monitors the target file until you kill it with a ctrl-C.

Regards,
Kent

[MooicIan]

Ahhh, that's where it is. I'd worked out that moode.log didn't bother with such details.

Thank you!

[Tim Curtis]

There is a library update summary thats written to the moOde log.

[MooicIan]

I am surprised at how slow the import is - about one track every two seconds. Presumably it's reading the whole file looking for tags.

[Tim Curtis]

That is very slow.

Slow throughput can be tricky to debug but the general approach is to first isolate the bottleneck by looking at performance statistics on the three main components: client, server, and network.

- What audio format(s) are the files?
- Look at the output of ifconfig and ifconfig commands to get a sense of whether there are network errors, retransmits, collisions etc.
- Run a ping test from the client to the server to see what the round trip times look like.

[MooicIan]

That is very slow.

Slow throughput can be tricky to debug but the general approach is to first isolate the bottleneck by looking at performance statistics on the three main components: client, server, and network.

- What audio format(s) are the files?
- Look at the output of ifconfig and ifconfig commands to get a sense of whether there are network errors, retransmits, collisions etc.
- Run a ping test from the client to the server to see what the round trip times look like.

Virtually all .MP3

The one that works better:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.88.22  netmask 255.255.255.0  broadcast 192.168.88.255
        inet6 fe80::70eb:3ba0:88b2:7a08  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:cb:9f:5b  txqueuelen 1000  (Ethernet)
        RX packets 44146047  bytes 41117865983 (38.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 14068122  bytes 1440127724 (1.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Sample ping:

64 bytes from 192.168.88.59: icmp_seq=1 ttl=128 time=7.72 ms
64 bytes from 192.168.88.59: icmp_seq=2 ttl=128 time=4.81 ms
64 bytes from 192.168.88.59: icmp_seq=3 ttl=128 time=6.49 ms

The one that is slower:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.88.23  netmask 255.255.255.0  broadcast 192.168.88.255
        inet6 fe80::41bf:6861:fe07:f2a8  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:9f:92:da  txqueuelen 1000  (Ethernet)
        RX packets 301189  bytes 316485271 (301.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 116028  bytes 14561001 (13.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

(not up for nearly as long...)

64 bytes from 192.168.88.59: icmp_seq=1 ttl=128 time=5.14 ms
64 bytes from 192.168.88.59: icmp_seq=2 ttl=128 time=5.11 ms
64 bytes from 192.168.88.59: icmp_seq=3 ttl=128 time=5.14 ms

I don't have the ifconfig for the time it was refreshing its library.

[Tim Curtis]

That is very slow.

Slow throughput can be tricky to debug but the general approach is to first isolate the bottleneck by looking at performance statistics on the three main components: client, server, and network.

- What audio format(s) are the files?
- Look at the output of ifconfig and ifconfig commands to get a sense of whether there are network errors, retransmits, collisions etc.
- Run a ping test from the client to the server to see what the round trip times look like.

Virtually all .MP3

The one that works better:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.88.22  netmask 255.255.255.0  broadcast 192.168.88.255
        inet6 fe80::70eb:3ba0:88b2:7a08  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:cb:9f:5b  txqueuelen 1000  (Ethernet)
        RX packets 44146047  bytes 41117865983 (38.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 14068122  bytes 1440127724 (1.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Sample ping:

64 bytes from 192.168.88.59: icmp_seq=1 ttl=128 time=7.72 ms
64 bytes from 192.168.88.59: icmp_seq=2 ttl=128 time=4.81 ms
64 bytes from 192.168.88.59: icmp_seq=3 ttl=128 time=6.49 ms

The one that is slower:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.88.23  netmask 255.255.255.0  broadcast 192.168.88.255
        inet6 fe80::41bf:6861:fe07:f2a8  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:9f:92:da  txqueuelen 1000  (Ethernet)
        RX packets 301189  bytes 316485271 (301.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 116028  bytes 14561001 (13.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

(not up for nearly as long...)

64 bytes from 192.168.88.59: icmp_seq=1 ttl=128 time=5.14 ms
64 bytes from 192.168.88.59: icmp_seq=2 ttl=128 time=5.11 ms
64 bytes from 192.168.88.59: icmp_seq=3 ttl=128 time=5.14 ms

I don't have the ifconfig for the time it was refreshing its library.

The long ping times suggest a possible network bottleneck. Ping times between two devices connected via Gbit Ethernet home runs to a Router are typically < 0.5ms avg and should have 0% packet loss.

Example:

Code:

pi@trx:~ $ ping moode-dev64
PING moode-dev64.home (192.168.1.134) 56(84) bytes of data.
64 bytes from moode-dev64.home (192.168.1.134): icmp_seq=1 ttl=64 time=0.820 ms
64 bytes from moode-dev64.home (192.168.1.134): icmp_seq=2 ttl=64 time=0.327 ms
64 bytes from moode-dev64.home (192.168.1.134): icmp_seq=3 ttl=64 time=0.330 ms
64 bytes from moode-dev64.home (192.168.1.134): icmp_seq=4 ttl=64 time=0.382 ms
64 bytes from moode-dev64.home (192.168.1.134): icmp_seq=5 ttl=64 time=0.424 ms
64 bytes from moode-dev64.home (192.168.1.134): icmp_seq=6 ttl=64 time=0.325 ms
64 bytes from moode-dev64.home (192.168.1.134): icmp_seq=7 ttl=64 time=0.322 ms
64 bytes from moode-dev64.home (192.168.1.134): icmp_seq=8 ttl=64 time=0.321 ms
^C
--- moode-dev64.home ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7011ms
rtt min/avg/max/mdev = 0.321/0.406/0.820/0.160 ms
pi@trx:~ $

[MooicIan]

100 Mbit home network :/ using mains networking between rooms here.

So it's not-really Gbit networking of Pi 3 over 200 Mbit mains network to 100 Mbit router, then over 200 Mbit mains network to Gbit miniPC...

At some point, I will upgrade to a Gbit router and get some 500 Mbit mains network kit, but for nearly everything it's fast enough now, especially as the actual internet connection is 100 Mbit. It can certainly stream music when others are streaming video ok.