roSlideShow and 3.0

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