Closed GoogleCodeExporter closed 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
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
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
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
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
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:
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
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
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
Original comment by basrie...@gmail.com
on 10 Feb 2013 at 10:34
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
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
Issue 424 has been merged into this issue.
Original comment by basrie...@gmail.com
on 27 Mar 2013 at 7:29
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
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
Let's merge these two issues.
Original comment by basrie...@gmail.com
on 17 Apr 2013 at 8:37
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
Please follow up in issue 423.
Original comment by basrie...@gmail.com
on 18 Apr 2013 at 11:33
Original issue reported on code.google.com by
arnov...@gmail.com
on 3 Feb 2013 at 5:51