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.
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.
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.
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.” 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.
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.
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
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
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.
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.
thank you all for your input, and thank you RokuMarkn for pointing us in right direction
You Rock. Our Dev Team solve this server side problem and we are back online.