This occurs with 2 different Receivers, both running standard Rio software. The server is YARRS on linux. For those who don't know YetAnotherRioReceiverServer is basically an apache virtual server, with some perl cgi scripts to respond to the requests from the Receiver.

When I select Playlist in the Receivers menu it returns the following error

Database error
Item is not a playlist.

If I simply use a browser and enter the same URL that the Receiver is trying to access

http://myserver/tags/100 (100 being the name of the master playlist file)

I get the apparently correct contents of the file.

If I make this playlist file smaller (10 lines), the Receiver is happy and displays the list. If I then put back the entire original file (whether it is the same real file/inode or not) it still works perfectly (and browsing the URL displays exactly the same as before) - until I remove power from the Receiver and it has to cold boot, after which it will fail again with the same arror until I play with the file as before.

Neither the YARRS developer nor Hugo at Rio are any help here, so I wondered if anyone here has any idea why the Rio Receiver player program might be generating that error. If I knew what caused the error I'd have a chance at effecting a cure, but right now I'm a bit stuck. I want to develop the YARRS stuff a bit more to provide nested/heirarchical playlists and tracks in number order, but no point in brushing up my perl until I have this cracked.

Anyone able to offer any help here?

You did not say how many songs were in the playlist that was failing. If it is a large number of songs, you are likely running into this problem.

It's the Master Playlist that I cannot get past. This is the first playlist it is sent when you Select Music/Playlists from the menu on the RR. This actual playlist file at the moment lists all the albums and is 825 lines long. There's no actual tracks in this list, just pointers to the album playlist files that contain the list of tracks and pointers to the actual music files, but I can't get that far. I select Playlist and it goes away for a second (so it's trying) and returns the error. The access log shows it tries to GET the URL 2 or 3 times then it gives up (and presumably then shows the error message).

I don't see how a list of 825 items should be a problem, especially when after the file is temporarily truncated the RR is quite happy with the full sized original.

How sensitive is it to funny characters, i.e. not regular ascii?

Found out some more info about this problem.

The Master Playlist File will cause an error when accessed after a cold boot and it is 18873 bytes or larger. Once it has been truncated (even one byte will suffice) it will then work perfectly until the next re-boot, even if it is subsequently made larger again.

The MPF works perfectly every time if its size is 18872 bytes or less.

I cannot see that the server has anything to do with this.

Also, if I try to access Select Music/Title (over 10,000 songs) the player application crashes and re-starts.

Are these some fundamental limits to the Receiver's player application? I know there are some limitations and I can accept or work around them, but I just don't understand why the playlist limit exists only until it accesses a smaller (below the limit) file then runs perfectly on much larger files until a cold re-boot.

Anyone any clues?

Next...

I created a very small Master Playlist File (1 line) that just pointed to the large playlist file that was a problem as the MPF. Re-booted the Receiver and unsurprisingly it loaded this first little playlist no bother, but it then worked perfectly when I selected the only option and it loaded the big one.

So, it would appear that this problem relates to the first playlist the Receiver accesses after first (cold) booting. This HAS to below a size limit, thereafter it can handle any larger playlist, but the first one is limited in size (although you can make it larger after the first successful access).

My guess is this has to be a player software issue, so with a re-structuring of the playlists I think I can avoid it. But worth knowing it is there.

Any comments on my analysis?

Anyone able to try a large playlist and see if they get the problem, even with ARM on Windows?