Request Failed: -3: An unexpected problem (but not server ti

I do not know what just happen like 5 days ago one of my Europen Music Chanel links stop working.
I did not update the zip or make any modification on my server. All other channels i have are working good.

Can I ask someone the test this link it play on local browser and it played on ROku for last 6 months as the other songs.

here is the sample link : http://telestream.interia.pl/teledyski/HQ/q/s/Ania_Wyszkoni0_Ania_25550.ehfjw

All i got is : " Request Failed: -3: An unexpected problem (but not server timeout or HTTP error) has been detected."

Looks like some new firmware overnight update again broke my channel.

k:

What kind of file is this?

Roku firmware for the original series was updated at the end of last year, as was firmware for the Roku2. Perhaps the company where you host your servers made some changes to their network, or automatic software updates ran on your server, lots of things that can happen.

  • Joel

There’s nothing wrong with the file. I can download it and play it. When I try to play it directly from the link on my XD|S, I get “play failed: Network error. This could be caused by any of the following problems: (1) The server is down or unresponsive. (2) The server is unreachable. (3) There is a network setup issue on the client.” Worse, when I try it on my Roku 2 XS, the box crashes and reboots.

-JT

The stream plays fine using VLC Media Player, but when I try to play it on my Roku 1 (version 3.1/1011), I get the following error:

Network error.  This could be caused by any of the following problems: (1) The server is down or unresponsive. (2) The server is unreachable. (3) There is a network setup issue on the client.

Here’s the output from mediainfo (I had to change the filename extension from ehfjw to mp4 for mediainfo to work):


General
Complete name                    : C:\Users\A\Downloads\Ania_Wyszkoni0_Ania_25550.mp4
Format                           : MPEG-4
Format profile                   : Base Media
Codec ID                         : isom
File size                        : 22.6 MiB
Duration                         : 3mn 52s
Overall bit rate mode            : Variable
Overall bit rate                 : 815 Kbps
Encoded date                     : UTC 2011-11-10 13:24:39
Tagged date                      : UTC 2011-11-10 13:24:39

Video
ID                               : 1
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.1
Format settings, CABAC           : Yes
Format settings, ReFrames        : 4 frames
Codec ID                         : avc1
Codec ID/Info                    : Advanced Video Coding
Duration                         : 3mn 51s
Bit rate mode                    : Variable
Bit rate                         : 750 Kbps
Maximum bit rate                 : 1 792 Kbps
Width                            : 720 pixels
Height                           : 404 pixels
Display aspect ratio             : 16:9
Frame rate mode                  : Constant
Frame rate                       : 25.000 fps
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : Progressive
Bits/(Pixel*Frame)               : 0.103
Stream size                      : 19.8 MiB (88%)
Writing library                  : x264 core 113 r1884 7313bb5
Encoding settings                : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=750 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Encoded date                     : UTC 2011-11-10 13:19:53
Tagged date                      : UTC 2011-11-10 13:24:39

Audio
ID                               : 2
Format                           : AAC
Format/Info                      : Advanced Audio Codec
Format profile                   : HE-AACv2 / HE-AAC / LC
Codec ID                         : 40
Duration                         : 3mn 52s
Bit rate mode                    : Variable
Bit rate                         : 96.0 Kbps
Maximum bit rate                 : 105 Kbps
Channel(s)                       : 2 channels / 2 channels / 2 channels
Channel positions                : Front: L R / Front: L R / Front: L R
Sampling rate                    : 48.0 KHz / 48.0 KHz / 24.0 KHz
Compression mode                 : Lossy
Stream size                      : 2.66 MiB (12%)
Encoded date                     : UTC 2011-11-10 13:24:39
Tagged date                      : UTC 2011-11-10 13:24:39

I wonder if the Roku doesn’t like the weird filename extension.

Check against the encoding guide in the SDK. 25FPS isn’t supported.

“Check against the encoding guide in the SDK. 25FPS isn’t supported.” Patrick all EU videos are encoded in 25FPS rate we have PAL system not NTSC like 29FPS this is not a issue with the frames,
same videos worked on Roku for over 6 months and we had no problem with the links or extensions it just stop working few days back.
if is not Roku engines updates it must be us.
I just need this to get fixed and looking for solution.

This might be a longshot, but I had that error before when I had by accident a .mp4 file that was not an xml file in my xml directory on my server and it gives that error. Removed the file and all was good. Plus, can’t trust Handbrake for fps. I had a video at 29.97 and still reported 25 on many videos.

Here yet another link from the same server. And this links also plays with the latest roku firmware:
http://telestream.interia.pl/teledyski/HQ/n/9/Kawa5_KawaLato_Pali_25265.yfcz9
It has also 25 fps. So why other links broken???

There is a problem in the ctts tables in those encodings.

This is what a normal ctts looks like:


00 00 00 01 00 00 03 e9 00 00 00 01 00 00 0b bb 
00 00 00 02 00 00 00 00 00 00 00 01 00 00 0b bb 
00 00 00 02 00 00 00 00 00 00 00 01 00 00 0b bb 
00 00 00 02 00 00 00 00 00 00 00 01 00 00 0b bb 
etc.

Each entry is two 4-byte words, the first is a count and the second a time offset. Note the count values in this example are 1, 1, 2, 1, 2, etc …

This is what the ctts looks like in the first URL you posted:


00 02 00 00 00 01 00 00 00 03 00 00 00 01 00 00 
00 01 00 00 00 01 00 00 00 03 00 00 00 01 00 00 
00 01 00 00 00 0e 00 00 00 02 00 00 00 01 00 00 
00 03 00 00 00 01 00 00 00 01 00 00 00 0a 00 00 
etc

This doesn’t make sense when interpreted as 4 byte integers. It seems to be using 2-byte (16 bit) values. I have not found any reference to 16 bit values being allowed in this atom, but perhaps there’s some extension that I’m not aware of. In any case, the Roku player does not support this and expects ctts to hold 32-bit values.

–Mark

wow, I have no idea what this means , but again we had the all links working fine till 5 days ago
and there is no way they re-encode 1.5TB of data just to make CTTS table errors , and they did not change any way they encode

Mark, I think you’re off by two bytes. This is what I see:


ctts 00 00 00 00 00 00 14 57 00 00 00 01
     ^  ^        ^           ^
     |  flags    entries     1st entry
     version

I think everyone’s also missing the part where the video can be played if I download it and play it from my local server. I can also do a roUrlTransfer and save it to tmp:/ and play it from there.

I think the really interesting thing is that this code will crash my Roku 2 XS:

Sub RunUserInterface()
    screenFacade = CreateObject("roPosterScreen")
    screenFacade.showMessage("Ania")
    screenFacade.show()

    port = CreateObject("roMessagePort")
    videoScreen = CreateObject("roVideoScreen")
    videoScreen.setMessagePort(port)
    videoScreen.SetPositionNotificationPeriod(10)

    videoclip = {}
    videoclip.StreamUrls = ["http://telestream.interia.pl/teledyski/HQ/q/s/Ania_Wyszkoni0_Ania_25550.ehfjw"]
    videoclip.StreamFormat = "mp4"
    videoclip.ContentType = "movie"
    videoclip.title = "Ania test"
    videoclip.StreamBitrates = [0]
    videoclip.playstart = 0
    videoclip.StreamQualities = ["SD"]

    videoScreen.SetContent(videoclip)

    log = CreateObject("roSystemLog")
    log.SetMessagePort(port)
    log.EnableType("http.connect")
    log.EnableType("http.error")

    videoScreen.show()

    while true
        msg = wait(0, port)
        if type(msg) = "roVideoScreenEvent"
            if msg.isScreenClosed() then 'ScreenClosed event'
                print "Closing video screen"
                exit while
            else if msg.isPlaybackPosition() then
                nowpos = msg.GetIndex()
                print nowpos
            else if msg.isRequestFailed()
                print "play failed: "; msg.GetMessage()
            else if msg.isFullResult()
                print "isFullResult"
                nowpos = -1
            else if msg.isPartialResult()
                print "isPartialResult, nowpos = ";nowpos
            else if msg.isStreamStarted()
                print "isStreamStarted"
                info = msg.GetInfo()
                for each i in info
                    print i,info[i]
                end for
            else
                print "Unknown event: "; msg.GetType(); " msg: "; msg.GetMessage()
            end if
        else
            print "Event: ";type(msg)
            print msg.GetInfo()
        end if
    end while

    print "Exiting app"
    screenFacade.showMessage("")
    sleep(25)
End Sub

-JT

That file crashes Quicktime on Windows as well…

Ok, sorry, I was confused by the real problem, which is that this server is handling range requests very strangely.

If I download the file with no range requests, I get a valid MP4 file.
If I download the file with the range request “0-” (which also requests all of the file), I get a DIFFERENT file. This is invalid server behavior and is causing the problems.

BTW, if I download the complete file to my server (which handles range requests correctly) and play it from there, it plays fine.

–Mark

I noticed that (probably should have mentioned it). If I use curl -r 0-, I get a slightly different file than if I just save it from Firefox. It’s interesting that some files seem to play ok and that some don’t since I see similar behavior with both links the OP provided.

-JT

thank you all for your input, and thank you RokuMarkn for pointing us in right direction :slightly_smiling_face:
You Rock. Our Dev Team solve this server side problem and we are back online.