[SOLVED] moOde 9.0.5 and 9.0.7: Adding radio station to playlist does not work

[Tim Curtis]

Did you try multiple times, as sometimes it works, sometimes not. Are you using wireless, as it works wired here.

I've spent my day on it, and the conclusion is that it works perfectly when I start from a fresh image. As from the moment I start restoring artifacts like playlists and radio stations, behavior is unpredictable.

The test I haven't done yet, is just restoring my radio stations and my config and prefs, instead of also restoring the playlists.

Today, I had to retry 7 times before I got the message "Items have been added", which is the proof that it actually happened.
I'm not a PHP guy, but what happens between "Updating Playlist" and the message "Items have been added"? As I don't get the 2nd message in case of failure, it looks like something is breaking the code in between those 2 steps. Also, why does it work when I retry 7 (can be another number as well) times?

I questioned myself why I haven't noticed this earlier? Well, quite simple... When I added radio stations, I added them to the Q containing my playlist of radio stations, and saved the Q to the playlist. This works. And this confirms me it's a software issue.

Yes I tried many times and could not get a failure. Each time I tested I waited for the "Items have been added" message to appear which typically took only 1 or 2 seconds.

The basic transaction flow is:
Client displays notification "Updating Playlist"
Client posts 'add_to_playlist' with data payload to server script /var/www/command/playlist.php
Client waits (asynchronously) for server script to complete
Server script carries out command, exits and returns control to client
Client wait ends, displays "Items have been added" notification

Maybe look at the Browser console when you get a failure case and see of there are errors.

[kurt1970]

So....
1) Fresh install
2) Restored Prefs, Radio stations, moOde stations
3)) Switched on radio service monitor (as it didn't get restored)

Everything works... I don't get it....

Next attempt, importing my playlists...

[the_bertrum]

Restoring moOde stations across versions can cause unexpected issues. If stations have been added or removed then the remaining stations can occupy different positions in the database. I've "lost" stations from the list several times until I stopped backing up moOde stations by default. That could be what throws your playlists out of whack.

[Tim Curtis]

Couple other things to try:

1. View the autocfg log (a record of applying the Configs and Prefs settings)
moodeutl --autocfglog
2. Connect the Pi via Ethernet and turn off the WiFi adapter
3. Instrument playlist.php script and see if it completes successfully

Add some logging statements to case 'add_to_playlist': in /var/www/command/playlist.php to see if it completes successfully. View the moode log via moodeutl -l

Code:

    case 'add_to_playlist':
        $plName = html_entity_decode($_POST['path']['playlist']);
workerLog('here0);
        // Get metadata (may not exist so defaults will be returned)
        $plMeta = getPlaylistMetadata($plName);
workerLog('here1);
        // Replace with URL if radio station
        if (count($_POST['path']['items']) == 1 && substr($_POST['path']['items'][0], -4) == '.pls') {
            $stName = substr($_POST['path']['items'][0], 6, -4); // Trim RADIO/ and .pls
            $result = sqlQuery("SELECT station FROM cfg_radio WHERE name='" . SQLite3::escapeString($stName) . "'", sqlConnect());
            $_POST['path']['items'][0] = $result[0]['station']; // URL
        }
workerLog('here2);
.
.
.
workerLog('here3);
        break;

[TheOldPresbyope]

@kurt1970 

Perhaps there's some magic combination of settings and actions that I haven't tried yet, but so far I'm unable to repro your problem on a fresh 9.0.5 player whether I restore your playlists and/or stations and/or Configs & Prefs or not. I think I'm repeating your steps but there's always a chance I'm missing something.

At this point I'm going to wait to see if you can manage to find a "smoking gun" on your end.

Regards,
Kent

[kurt1970]

I really appreciate all your efforts in helping to fix this.

As another try, I put the SSD on an USB2 port on the PI, instead of the USB3 port. No difference.

Tomorrow, as it is 23h25 CET here, I"ll wire it and restore the config of my other wired (working) device to figure out how it behaves. I'll put it on the same switch as where my other functioning moOde instance is on.

Overall experience is that it works to add a station to a playlist, as long as I keep trying. The nr of attempts is unpredictable. This makes me thinking about network timeouts. If it would be a plain vanilla bug, it would never work. Fact is that it works as long as you keep trying.

[kurt1970]

I guess the issue is nailed down.

The next test I wanted to do was to try it via a wired connection. In order to do that, I had to bring the PI closer to my WL router.

Before plugging in the cable, I did another WL test. Everything worked perfect, and this with my original configuration. To be sure, I rebooted a couple of times and did some more tests. All worked without any issue!

Plugging in the cable makes it just a lot faster.

So, it looks like WL distance was the issue, and explains why it often worked after a random number of retries.

How come that there are no traces of this?

Thanks again for thinking with me!

[the_bertrum]

That sounds like it explains things nicely. If the connection was weak, then the instruction would be "sent" from the client resulting in "Updating Playlist", but wasn't received by the server so it never added the items nor sent the trigger for the client to show the "Items have been added" message.

I find that using the mDNS names when the wireless network isn't perfect can often result in a player that's dropped temporarily but still appears to be on the network because the other devices in the network still have it's last known address. I have dropped back to reserving an IP for each player and then addressing them via that to eliminate the various mDNS caches.

[kurt1970]

That sounds like it explains things nicely.  If the connection was weak, then the instruction would be "sent" from the client resulting in "Updating Playlist", but wasn't received by the server so it never added the items nor sent the trigger for the client to show the "Items have been added" message.

I find that using the mDNS names when the wireless network isn't perfect can often result in a player that's dropped temporarily but still appears to be on the network because the other devices in the network still have it's last known address.  I have dropped back to reserving an IP for each player and then addressing them via that to eliminate the various mDNS caches.

I use IP reservations as well, and always address my instances via the IP address instead of its name.

[Tim Curtis]

For wireless stats run the ifconfig command. On a solid WiiFi network all the error stats will be 0.

Next run a 30 second ping test from the Pi to the Router. There should be 0% packet loss and average round trip time (rtt) prolly around 3 or 4 ms. Most ping times should be similar to one another.

Code:

ifconfig

ping LAN_ADDRESS_OF_ROUTER