Hi,

Apparently the reboot issue is caused by specific movies that are being indexed and causing some sort of issue with the XML parser in the firmware of the PlayOn.

Now hopefully, I can fix the issue using a combination of software changes or configuration, but I will need examples of the XML of movies that cause this issue and testers to see if the problem is fixed.

ACR have confirmed that "The Last Boy Scout" is a movie that causes this issue, so if someone could test if this is indeed an issue and provide the XML of the movie, that would really help.

Also if you know of any other movies that cause the issue. Please provide examples of the XML. You can post to pastebin and add the link here.

Note: You do not have to own the movie itself, you can either copy & rename an existing movie or just create an empty file and rename it e.g. "The Last Boy Scout.avi".

Please make sure it causes the PlayOn to reboot

Hi Omertron
The attached zip file contains a jukebox for The Last Boy Scout and was generated using YAMJ r2699 as per your request, and I can confirm that the POHD Mini (firmware 7.3.6.r4415) reboots once the index.htm file has been selected and the POHD tries to load / update the jukebox.
When I first tried r2699 on my full jukebox the POHD mini rebooted while trying to find the index file.
The only error in the log file was : -
[21:06:21 - Thread-7] WARN moviejukebox - Failed drawing Language logo to thumbnail file: The Last Boy Scout
[21:06:21 - Thread-7] WARN moviejukebox - Please check that language specific graphic (en-us.png) is in the resources/languages directory.
the .png file does not exist - even in YAMJ v2.4. No .nfo file was used
Hope this helps to find the problem
Andy

I can't see anything in the library file that you sent me (v2.5 r2699), or the one that ACR sent (v2.4 r2251) (of the same movie) that would cause the issue.

There don't seem to be any strange characters in there, or broken XML.
The plots are both short (so no overflow buffer issues)

I'm not sure what else I can look for, this seems to be an issue with the firmware, and I don't know enough about the way the firmware reads the files, what fields are read and how to make an educated guess at what might be wrong with this movie to cause this

hi

i often get the message "unable to service request" when selecting a movie from the jukebox, i use nfo files with title, imdb no and plot. most times the plot contains names in brackets, if i remove them from the plot the movie starts.

I think I've found the problem. The problem can be seen in YAMJ v2.4, using The Last Boy Scout as an example.
- I created an XML .nfo file to prevent YAMJ downloading anything from the IMDB website, which eliminated the IMDB data - the Mini still rebooted
- The SDK3 Jukebox generates .rss files when it 'updates' the Jukebox, or on a first use. Looking at these, the problem is with the Other_New_1 files. It crashes either during or as it exits generating the .rss file for Other_New_1.
- Removing Other_New_1.xml and Other_New_1.html files from the Jukebox directory gets around the problem and the Mini reads the jukebox and generates all of the other .rss files.

I've uploaded the YAMJ v2.4 Jukebox, including the .rss files, hope you can identify what's wrong with the Other_New_1 files.

Andy

P.S. If the Mini finds two index.html files on the same share, obviously in different directories, it reboots without displaying any index.html files to choose from. Not related to this problem but worth knowing

Ok, thanks Andy. Still not sure what is and isn't used in there.

Can you run the same test but with a movie that works?

Keep everything the same, except for the movie data and see if that causes the reboot. If you can then provide the XML and RSS files (I don't need the rest of the files) we can compare and contrast and see if it's the film or the file that causes the issue

OT:
Strange that they use RSS files, because we already generate a RSS skin (It's used by other players such as HiMedia (See here) so they could have used that rather than messing with the xml files.

Hi Omertron
I'll run some more tests either tonight or tomorrow and post the results. The SDK3 firmwares generate the .rss files - not sure about SDK4, I've not done a huge amount of investigation on SDK4 as the Jukebox usability is poor and not worth me upgrading to yet.
Andy

I've created another test Jukebox - using the movie A Bridge Too Far this time - again using V2.4.
A Bridge Too Far has never given me problems before - in fact YAMJ2,4 has never given me problems until I started testing single movies. Results are: -
- Mini reboots when trying to load the Jukebox for the first time
- Removing the Other_New_1 files, incliuding the .rss file from the Jukebox directory allows the jukebox to load, and every other index works.
- Restoring the three Other_New_1 files, and loading the Jukebox without updating works, except the 'New' page is blank, showing the .rss file was partially generated when the Mini rebooted.
- Any attempt to update the Jukebox from the Mini while the Other_New files are in the Jukebox directory causes a reboot.
I've attached the Jukebox again - smaller graphics files this time, but it's easier to zip up the whole lot. I'll try and find a Movie which does not cause the Mini to crash - but A Bridge Too Far never crashed it before
Andy

I created another test library, using the movie Jumper this time, with the same results.
Looking at the content of the Other_New_1.xml file, there is no movie information in it, despite the fact it's a new Jukebox and Jumper is the first movie in it - should there be?
And this stirs a brain cell or two as well. I remember occasionally noticing movies coming onto the new page in my full library, which I knew have been there for a long time, and the occasional new movie not appearing - don't know if this is relvant, I never had a reboot and didn't give it much thought at the time
Andy

New movies are based off the modified date of the movie file (or the movie directory if it's a VIDEO_TS or BDMV rip)