veveykocute / xot-uzg

Automatically exported from code.google.com/p/xot-uzg
0 stars 0 forks source link

Uitzendinggemist streams not seekable #411

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What channel are you trying to watch?

Uitzendinggemist.nl

What episode are you trying to watch?

*any*

What is the expected output? What do you see instead?

When skipping/stepping it should eg. go skip/step but instead it locks up and 
crashes XBMC.

What steps will reproduce the problem?
1. Play any episode from uitzendinggemist.nl
2. Small/large step forward
3. Lockup + crash

What version of XBMC are you using? On what operating system?

Tried both 11.0 and 12.0 on Linux-x86

Please provide any additional information below.

The problem seems to be in ffmpeg which doesn't play nice with the 
Silverlight(?) implementation on uitzendinggemist.nl. Seperate ffmpeg/ffplay 
has the same issues with all of these streams. I possible workaround could be 
having an option to either select the Silverlight or Flash version for 
uitzendinggemist streams or simply use Flash by default.

Original issue reported on code.google.com by arnov...@gmail.com on 3 Feb 2013 at 5:51

GoogleCodeExporter commented 8 years ago
That is not an XOT-Uzg.v3 issue, but a generic XBMC issue. That is not an 
XOT-Uzg.v3 issue, but a generic XBMC issue. 

If the stream starts, XOT's work is done and it's all up to XBMC.

Original comment by basrie...@gmail.com on 3 Feb 2013 at 6:25

GoogleCodeExporter commented 8 years ago
I know that since I'm an XBMC dev myself ;-) I'm just proposing a workaround as 
the problem is further downstream (ffmpeg)...

Original comment by arnov...@gmail.com on 3 Feb 2013 at 8:18

GoogleCodeExporter commented 8 years ago
Damn, didn't read that one. I think I can manage to get the Flash versions (I 
even think I do, but take the best one). Let me check

Original comment by basrie...@gmail.com on 3 Feb 2013 at 8:22

GoogleCodeExporter commented 8 years ago
I just checked: I have these options: 

WMV:
http://odi.omroep.nl/video/embedplayer/wmv_bb/e0e38f341a9857f1464f4b2734a0da2f/5
10ec91a/TROS_1336012/?type=asx
http://odi.omroep.nl/video/embedplayer/wmv_sb/e542ecd5d45d475baed57f7c32ff65da/5
10ec91a/TROS_1336012/?type=asx
http://odi.omroep.nl/video/embedplayer/wvc1_std/cd69f82f3a1f83a45ecc0a4682b2d379
/510ec91a/TROS_1336012/?type=asx

MOV:
http://odi.omroep.nl/video/embedplayer/h264_std/5d8f6ce199c3d93bb48c1e65f6e1328f
/510ec91a/TROS_1336012/?type=http&
http://odi.omroep.nl/video/embedplayer/h264_bb/bcc05aff6b92eebedb54fd212106d0e8/
510ec91a/TROS_1336012/?type=http&
http://odi.omroep.nl/video/embedplayer/h264_sb/b79fea44b580b6f455fd26edaf6b41d9/
510ec91a/TROS_1336012/?type=http&

At the moment for the Uitzendinggemist.nl channel (not the mobile channel), I 
use the MOV versions and those cannot seek. However, if I switch to the WMV 
version (change the isApple to False in line 431 of the chn_nos2010.py file), I 
can seek, but then XBMC will crash. 

The mobile version uses M3U8 files and they seem to work fine. I could try 
those first for the non-mobile version to, but I am not sure that all 
non-mobile videos have mobile streams. I will check.

Original comment by basrie...@gmail.com on 3 Feb 2013 at 8:39

GoogleCodeExporter commented 8 years ago
In the meantime I'll also perform some tests concerning the crash with the WMV 
version (probably another ffmpeg issue). I wonder why ffmpeg is specifically 
having problems with the streams on uitzendinggemist.nl, since it works fine 
with ordinary wmv/mov files...

Let me know as soon as you've figured out whether we can make m3u8 work as that 
seems to be the most viable solution for now.

Original comment by arnov...@gmail.com on 4 Feb 2013 at 6:30

GoogleCodeExporter commented 8 years ago
Ok, I managed to get some stuff working: 

I now 'try' to get the mobile URL from the non-mobile metadata and see if I can 
get M3U8 data from that URL. If that returns nothing, I fallback to the normal 
streams. 

For recent episodes the M3U8 url's should be available, but older ones probably 
not. 

You can try the attached file and see if it works. If you put the logging of 
XOT to debug (new features in 3.3.3) you will see if it manages to get the 
correct URL. 

Original comment by basrie...@gmail.com on 4 Feb 2013 at 9:03

Attachments:

GoogleCodeExporter commented 8 years ago
Thanks for looking into this. I'll check the .py as soon as I have the time. 
Note that I also wrote a patch/fix for XBMC to address this issue, here: 
https://github.com/arnova/xbmc/commit/b5336af80cde4914d7f01419ea75e3e87bdf397d 
But I'm not sure yet if and when it will be included into mainline.

Original comment by arnov...@gmail.com on 6 Feb 2013 at 9:15

GoogleCodeExporter commented 8 years ago
Unfortunately my patch doesn't 100% fix the problem, it's like there's an 
additional problem in the FFMPEG version that ships with XBMC 12.0 . It also 
looks like the m3u8 links point just point to the Silverlight streams, which 
doesn't help much. But maybe I missed something?

Original comment by arnov...@gmail.com on 6 Feb 2013 at 2:08

GoogleCodeExporter commented 8 years ago
The M3U8 Stream does not point to the silverlight streams as far as I know. 
They point towards URLs like: 

http://odcontent-e99c1b.npostreaming.nl/codem/h264/1/nps/rest/2013/NPS_1221563/N
PS_1221563.ism/NPS_1221563.m3u8

Original comment by basrie...@gmail.com on 6 Feb 2013 at 7:25

GoogleCodeExporter commented 8 years ago

Original comment by basrie...@gmail.com on 10 Feb 2013 at 10:34

GoogleCodeExporter commented 8 years ago
I discovered one issue with the m3u8 streams: a lot of them return 404 errors 
after being redirected to the actual content server. E.g.: from the Sesamstraat 
streams only 50% work.

I don't how that is if you play them from an Apple device using the app? 
Perhaps somebody can check? 

Original comment by basrie...@gmail.com on 16 Feb 2013 at 11:22

GoogleCodeExporter commented 8 years ago
I updated the net.rieter.xot.channel.nos channel to 3.3.3.1 and it now uses the 
Android streams, even though they are not m3u8, they do all work. 

Original comment by basrie...@gmail.com on 26 Feb 2013 at 1:27

GoogleCodeExporter commented 8 years ago
Issue 424 has been merged into this issue.

Original comment by basrie...@gmail.com on 27 Mar 2013 at 7:29

GoogleCodeExporter commented 8 years ago
For me the issue has improved after updating to Frodo (XBMC v12.1 on OS-X 
10.6.8)
Where on Eden (XBMC v11.x) skipping through or resuming material would result 
in a scrambled image (mostly grey), the same actions in Frodo will play the 
content.

Though unfortunately the problem wasn't solved because after while the player 
will experience buffering issues or stop playing all together - only after 
skipping through or resuming the stream. 

Restarting the stream from the XBMC playlist (not the stream list) will result 
in an error:
"Uw sessie is verlopen, herlaad de pagina" which is actually a 'error-stream' 
being displayed. 
I assume this indicates the cookie is expired
This together with the behavior in eden when skipping through the material 
makes me suspect the DRM protection to cause the issue if there is any. 

I respect that the XOT-UZG is just passing on information to the XMBC engine. 
Though I do not experience any similar behavior with other channels within the 
XOT-UZG or other plugins. Please keep investigating.

Original comment by tijnep...@gmail.com on 17 Apr 2013 at 8:09

GoogleCodeExporter commented 8 years ago
If you use the Program version of XOT-Uzg.v3 you might have this issue with 
expires sessions as it caches the media url. Try the plugin version. That one 
actually determines the URL on each playback. 

For the skipping/resuming: in XBMC 12.1 something got messed up with streaming 
particular MP4 streams, such as the NOS streams. Particular on non-windows 
systems this is causing issues. I myself rolled back to XBMC 12.0 (which is 
database-wise 100% compatible with other 12.1 XBMC versions) to get back to 
working streams. 

I will see what XBMC 12.2 brings us and then see what actions to take.

Original comment by basrie...@gmail.com on 17 Apr 2013 at 8:33

GoogleCodeExporter commented 8 years ago
Let's merge these two issues.

Original comment by basrie...@gmail.com on 17 Apr 2013 at 8:37

GoogleCodeExporter commented 8 years ago
I cannot find an XMBC issue that discribes this issue.
Does anyone know if this has already been addressed at the right location?

Original comment by tijnep...@gmail.com on 18 Apr 2013 at 11:29

GoogleCodeExporter commented 8 years ago
Please follow up in issue 423.

Original comment by basrie...@gmail.com on 18 Apr 2013 at 11:33