It looks like roSlideShow pretty much doesn’t work at all under 3.0. I can occasionally get a photo to display, but for the most part all I get are a bunch of isRequestFailed events with an index of -3. The index is supposed to be the index of the photo for which the request failed, so -3 makes no sense whatsoever (and it’s always -3).
-JT
I just did a quick test of roSlideShow on v3.0 and it seems to work fine… Is there a particular example you can share that seems broken??
–Kevin
I knew you were going to say that! 
It’s from the MyMedia channel which hasn’t changed. I can get some photos to work, or the first of a large group will sometimes work and then the multitude of isRequestFailed events. I’ll see if I can boil it down to a smaller example.
However, what of the -3 index for isRequestFailed? Surely that points to something being wrong.
-JT
“renojim” wrote:
However, what of the -3 index for isRequestFailed? Surely that points to something being wrong.
I don’t know if it’s related or not, but -3 is the curl error code for “malformed URL”. :?:
Interesting and all the more so since I just discovered that if you do give it a URL to something that doesn’t exist the message index returned from the isRequestFailed event will be -3. However, the index is supposed to be the index of the content list item so you can track down which image is causing the problem. So, I’d have to say there’s a bug somewhere.
-JT
Any chance there are spaces or other special characters in the file names of the pictures that don’t display? I’ve notice 3.0 is a lot stricter about stuff like that, so something like that might have worked in 2.9, but not 3.0..?
Thanks, but I think I’ve figured out what the problem is (this Python server is killing me). Still, there’s no reason for the “-3” index.
Ok, let me guess - 3.0 uses range requests for roSlideShow and the old firmware didn’t, right? I have to say, watching the traffic via Wireshark, the whole process looks about as inefficient as it could possibly be. There’s several (fully satisfied) requests for each photo and they’re only about 36k each. The previous firmware never made more than one request.
-JT
“renojim” wrote:
Thanks, but I think I’ve figured out what the problem is (this Python server is killing me). Still, there’s no reason for the “-3” index.
If the -3 did mean “malformed URL”, I was trying to think of reasons it might think it was malformed.
“renojim” wrote:
Ok, let me guess - 3.0 uses range requests for roSlideShow and the old firmware didn’t, right? I have to say, watching the traffic via Wireshark, the whole process looks about as inefficient as it could possibly be. There’s several (fully satisfied) requests for each photo and they’re only about 36k each. The previous firmware never made more than one request.
Sounds a lot like the “Problem 1” described here: viewtopic.php?f=34&t=39272&p=263775#p261632
It looks like that -3 may be some default if there is any problem with the request. By the way, I tried using roSystemLog to see if I could get any more information, but no events fired. I guess it doesn’t work for all requests; maybe only video?
I don’t know if it’s related to “Problem 1”, but boy it sure does look like the firmware is inefficient at times.
-JT
The roSlideShow component has always required range requests… It’s possible the chunk size has changed.
–Kevin
Interesting. It must have had a huge chunk size so that it never needed them. It never used them or I’d have never been able to view photos and that multiple request thing (not ranges, the whole file) is definitely new.
Any comment about the -3 index?
-JT
Not sure how I missed this before, but in the documentation for the isRequestFailed() event for the roVideoScreen, there is a reference to the -3 error code.
• When you get an error code of -3, the Roku Internal Error number may have further meaning to Roku Developer Support.
• It’s good to record these roku internal errors whenever you get a -3 Error number.
That’s interesting, but that is for roVideoScreen and not roSlideShow. The Index for roVideoScreen returns an error code whereas for roSlideShow it should return the index of the “problem” slide presumably so you can tell which one is the problem slide. It still might be worthwhile to see if the Data gives any kind of internal error code, although the documentation says Data will equal 0 for isRequestFailed().
-JT
“renojim” wrote:
That’s interesting, but that is for roVideoScreen and not roSlideShow. The Index for roVideoScreen returns an error code whereas for roSlideShow it should return the index of the “problem” slide presumably so you can tell which one is the problem slide. It still might be worthwhile to see if the Data gives any kind of internal error code, although the documentation says Data will equal 0 for isRequestFailed().-JT
I know it’s for a different component. I just thought it was too much of a coincidence to not mention it when I ran across it today. Maybe the behavior was changed in 3.0 and the documentation wasn’t updated, or maybe the documentation is just wrong… or maybe it’s coincidence…
