importsfromgooglecode / xot-uzg

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

Uitzending gemist stream stops working half way #423

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What channel are you trying to watch?
Uitzendinggemist.nl

What episode are you trying to watch?
- Sesamstraat (last 4 episodes)
- Proefkonijnen (one episode)
- Woezel en pip (one episode)

What is the expected output? What do you see instead?
See the whole episode
It just stops somewhere halfway and you see the last "Folder" in xmbc.

What steps will reproduce the problem?
1. Start XMBC
2. Start UZG addon
3. Start any episode of Sesamstraat and try to watch it to the end (mine all 
quit around 15/16 minutes, no skipping ahead)

What version of XBMC are you using? On what operating system?
XBMC 12.1
UZG 3.3.5
OS Windows 7

Please provide any additional information below.

Please ATTACH a complete DEBUG uzg.log or uzgplugin.log and add an
xbmc.log. Without a logfile issues cannot be fixed. Wondering where
you can get them? Read it here:
http://www.rieter.net/pages/XOT:Troubleshoot

I"ve attached uzgPlugin.log
Can't find xbmc.log anywhere on my computer.
With stream in my log, that crashed at 13 minutes 16 seconds (it was around 
20:10. So looking at the log, I see nothing..it stopped when the stream started)

Original issue reported on code.google.com by patrick....@gmail.com on 27 Mar 2013 at 7:14

Attachments:

GoogleCodeExporter commented 9 years ago
Well, as soon as XOT-Uzg.v3 passes the stream to XBMC and it starts playing, 
XOT-Uzg.v3's work is done and it merely an XBMC task. But let me check. I am 
watching the "Sesamstraat - Ruilen" at the moment and see if it plays to the 
end. 

You can always try the  Mobile UZG channel. It has almost all episodes (just 
not the old ones) but uses other stream sources with the same (and often with 
even higher) quality. 

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

GoogleCodeExporter commented 9 years ago
First Sesamstraat played just fine. Starting a second one now.

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

GoogleCodeExporter commented 9 years ago
Second one just finished without any issues. So it seems that it is not 
XOT-Uzg.v3 related. Do you have any other systems to test on? Friends or 
co-workers?

Original comment by basrie...@gmail.com on 27 Mar 2013 at 8:23

GoogleCodeExporter commented 9 years ago
Thanks for the quick reply. Are you running 12.1 too? And uzg 3.3.4.?
On 11.0 it was running fine...
Maybe i need a clean reinstall? Ill try on a second machine too....
Op 27 mrt. 2013 20:53 schreef <xot-uzg@googlecode.com> het volgende:

Original comment by patrick....@gmail.com on 27 Mar 2013 at 10:10

GoogleCodeExporter commented 9 years ago
Mmm...second machine...just tried skipping ahead, that seems to work. No
buffering problems...
Didn't have time to look at an entire episode....
I'll try doing a fresh and clean reinstall on the other machine.
I'll let you know how that works out.

2013/3/27 Patrick Pennings <patrick.pennings@gmail.com>

Original comment by patrick....@gmail.com on 28 Mar 2013 at 12:24

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Hi Basje,
I have the same problem on my ATV2 but have it on every episode. It doesn't 
matter if it's UZG mobile or the regular one.
The log file is att. 
Thanks!

Original comment by jeroenho...@gmail.com on 28 Mar 2013 at 3:24

Attachments:

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Well, like I said: on all my devices they play just fine. I have a daughter 
that watches sesamstraat both on my PC, ATV2 and rPi using XOT-Uzg.v3 and we 
never ever have issues. So it's not the add-on, but some other network related 
issue. 

Could you post your debug xbmc.log? Perhaps it holds some clue.

Original comment by basrie...@gmail.com on 28 Mar 2013 at 4:28

GoogleCodeExporter commented 9 years ago
Issue 425 has been merged into this issue.

Original comment by basrie...@gmail.com on 29 Mar 2013 at 6:24

GoogleCodeExporter commented 9 years ago
Please try watching Proefkonijnen - Aflevering 1 Wo 14 Dec 2011. Anyone else 
experiencing buffering issues after 3:30 minutes?

Original comment by eskap...@gmail.com on 29 Mar 2013 at 9:43

GoogleCodeExporter commented 9 years ago
Just watched a Sesame street episode. I notice the cpu hitting 99% when the 
movie freezes and XBMC starts buffering every 30 sec. Could it be a XBMC issue? 
 The first 3 minutes were fine and no buffer / freezing btw.

I also tried The next pop talent from SBS6 (show 5 and 6) and I did not see any 
buffering issues btw.

All tests were done on two raspbmc (512mb) devices.

Original comment by eskap...@gmail.com on 29 Mar 2013 at 9:59

GoogleCodeExporter commented 9 years ago
No problems here with the Proefkonijnen. 

I know it sounds crazy, but could you try this at a completely different time 
as you would normally do this? Because I think that you are all running out of 
buffer in XBMC somehow. XBMC tries to rebuffer and continue playback. But due 
to a bug in ffmpeg (see http://code.google.com/p/xot-uzg/issues/detail?id=411) 
XBMC cannot resume from where it stopped (this error with resuming is causing 
the 99% CPU).

The buffer issue could be a NOS issue (limited bandwidth for the servers) or a 
local issue (limited bandwidth due to other internet/download activity or bad 
internet connection). Trying playback at another time might circumvent those 
bandwidth issues. 

Like I said before: I have a daughter that watches sesamstraat both on my PC, 
ATV2 and rPi using XOT-Uzg.v3 and we never ever have issues, but see watches 
during the mornings and/or afternoons.

Original comment by basrie...@gmail.com on 31 Mar 2013 at 8:11

GoogleCodeExporter commented 9 years ago
Ok did some more retesting with xbmc logs running....

I did a clean install and have these problems on two machines.
The problems are:

1. Roughly halfway an episode, it just stops working. I either get sent back to 
the directory screen in xmbc, but last time I got the nos screen saying my 
sessio has expired (or something like that.)

2. If I go directly to a certain point in the stream...it runs fine for about 
30 seconds and then the sound misses a frame sometimes and eventually it is 
buffering again...then it runs again for a few seconds and buffers again. (the 
enclosed xbmc.log is from this scenario).
I see a lot of these "19:17:47 T:6528 WARNING: CDVDMessageQueue(audio)::Get - 
asked for new data packet, with nothing available" the time sound stutters...
Also it seems like the session closes...
"19:17:45 T:4192    INFO: XCURL::DllLibCurlGlobal::CheckIdle - Closing session 
to http://odi.omroep.nl (easy=11850958, multi=00AD7FD0)" while it is not 
finished yet.

3. Sometimes the video is messed up..it looks like the frames are switched 
somehow.
Say I get frame 1 then frame 9, then frame 2, then frame 10 etc...
In the log I see this, but when creating this log, i did not notice this 
behaviour...
"19:17:45 T:5472   DEBUG: XFILE::CFileCache::Process, request seek on source to 
106488399
19:17:45 T:5472   DEBUG: XFILE::CFileCache::Process, request seek on source to 
110327388
19:17:45 T:5472   DEBUG: XFILE::CFileCache::Process, request seek on source to 
106493873
19:17:45 T:5472   DEBUG: XFILE::CFileCache::Process, request seek on source to 
110327468
19:17:45 T:5472   DEBUG: XFILE::CFileCache::Process, request seek on source to 
106499302
19:17:45 T:5472   DEBUG: XFILE::CFileCache::Process, request seek on source to 
110327548
19:17:45 T:5472   DEBUG: XFILE::CFileCache::Process, request seek on source to 
106501470
19:17:45 T:5472   DEBUG: XFILE::CFileCache::Process, request seek on source to 
110327628"
Are the source to numbers ok? Or is it trying to runs two streams simultane?

Original comment by patrick....@gmail.com on 1 Apr 2013 at 11:56

Attachments:

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
To everybody: 
- please specifically state what channel you are using: the mobile or 
non-mobile version
- please specify if you are running in plugin or program mode (without or with 
the XOT userinterface)
- please always attach an uzg(plugin).log

Besides that:
You can't search these streams, that is an ffmpeg issue. 

From the tweakers.net thread it seems that it is mostly rPi and some Linux 
distro's that are suffering from this issue. With XBMC 12.0 it all seemed to be 
fine. For Raspbmc a new thread was created here: 
http://forum.stmlabs.com/showthread.php?tid=7957

Please post more info in that thread. 

Original comment by basrie...@gmail.com on 1 Apr 2013 at 12:13

GoogleCodeExporter commented 9 years ago
- loading up sesamstraat stream on the non-mobile version
- running in video addon mode (no special interface)

With 12.1 I seem to be able to search the stream...there is an issue, but with 
12.0 I couldn't search the stream at all.

I have the problem on a laptop and a normal PC. Both running windows 7, i'll 
try to go back to 12.0 and see if that helps.

Regards

Original comment by patrick....@gmail.com on 1 Apr 2013 at 3:05

GoogleCodeExporter commented 9 years ago
I just reverted my Raspbmc to the xbmc-rbp-20130305 nightly build and that 
fixed the playback issues.

This nightly is the last 12.0 based nightly and I guess it won't break anything 
else, but I cannot guarantee that.

Original comment by basrie...@gmail.com on 1 Apr 2013 at 4:06

GoogleCodeExporter commented 9 years ago
Same for Windows 7 machine.
Reverted back to 12.0 (was on 12.1), not all episodes play fine!
The downside is I can't do "jump to xx:xx", but he...this is better then 12.1...
I also tried the lasted nightly build, but that has the same issue for me as 
12.1.

What version are you running on the PC machine, Bas? 12.1 or 12.0? And not 
having issues with playback of Sesamstraat?
I've tried 12.1. on two machines, tested several episodes, and all stop working 
after 10 - 18 minutes.....

Original comment by patrick....@gmail.com on 3 Apr 2013 at 5:27

GoogleCodeExporter commented 9 years ago
On PC I run 12.1, on ATV2 12.1 and both run fine. 

On rPi I just upgraded to 12.1 again and modified the 
.xbmc-current/xbmc-bin/share/xbmc/system/advancedsettings.xml and changed (so 
not the standard/user advancedsettings.xml):

<cachemembuffersize>2097152</cachemembuffersize>

to 

<cachemembuffersize>20971520</cachemembuffersize>

running a test now.

Original comment by basrie...@gmail.com on 3 Apr 2013 at 6:42

GoogleCodeExporter commented 9 years ago
Hi, I am also having the problem that Uitzending gemist streams stop after 
around 15 minutes. My kids watch Sesamstreet regularly, an episode is about 25 
minutes but after 15 minutes the playback stops and you return to the list of 
episodes again. You can resume the episode from where it stopped, but then 
after a few seconds the playback is paused for buffering, then it plays for a 
few seconds to pause again for buffering etc.

I am watching the non-mobile channel. I am running XBMCbuntu 12.1 with Xot 
3.3.4.

This problem was introduced after upgrading from 12.0 to 12.1. I had no 
problems when I ran 12.0 (or 11.0).

What I tried since the problem was introduced:
* downgrade to 11.0 -> the problem remains
* upgrade to development 13.0 alpha -> the problem remains
* play the mobile channel -> the problem remains

I have attached both the xbmc.log and uzgPlugin.log. Playback of the stream 
starts at  9.50 PM and then suddenly it stops at 10.06 PM (the line is marked 
with @@ in both log files).

I really hope this can be resolved. I cannot determine whether this is a Xot 
problem or an XBMC problem, please let me know if I need to create a ticket in 
the XBMC bug tracker.

Best regards,
Geert

Original comment by geert.gr...@gmail.com on 15 Apr 2013 at 8:52

Attachments:

GoogleCodeExporter commented 9 years ago
This issue was indeed introduced in 12.1 and will hopefully be fixed in 12.2 
(undergoing beta testing at the moment). If you want you could try out their 
12.2 test builds (http://xbmc.org/natethomas/2013/04/09/xbmc-12-2pre-testing/). 
I only have the issue on my rPi (which I reverted to 12.0 to solve the issue 
for now), so I can't verify if the 12.2 fixes the issue.

Original comment by basrie...@gmail.com on 15 Apr 2013 at 8:55

GoogleCodeExporter commented 9 years ago
Thanks for the quick reply! I was looking at the test builds but there does not 
seem to be an XBMCbuntu version available yet. I will wait for that.

Original comment by geert.gr...@gmail.com on 15 Apr 2013 at 9:00

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I am having the issue again on my 12.0 installation. Which was running fine 
earlier after I reverted back to that..
Arrgghhh...
The sesamstraat episode all now stop somewhere between 40 and 60%. Also it 
seems random, if I rerun an episode again, it will surely crash but not at the 
exact same time as the previous run did...
I'll try the latest builds...

Original comment by patrick....@gmail.com on 17 Apr 2013 at 5:23

GoogleCodeExporter commented 9 years ago
Tested with 16 april version of 12.2...
After a do a quick search forward...after about 60 seconds it starts stuttering 
again and then buffers again. My internetconnection is certainly fast enough to 
get the feed.

I've included the xbmc.log

Original comment by patrick....@gmail.com on 17 Apr 2013 at 5:35

Attachments:

GoogleCodeExporter commented 9 years ago
Perhaps you can see if such issues are already report on the XBMC forum? At the 
moment I am too busy to go and test the 12.2 version myself. Besides that, on 
my main PC (windows) I don't even have this issue, nor on my ATV2. It's just my 
rPi that is have this issue and they don't have a 12.2 version yet to test.

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

GoogleCodeExporter commented 9 years ago
Issue 411 has been merged into this issue.

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

GoogleCodeExporter commented 9 years ago
Issue 411 has been merged into this issue.

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

GoogleCodeExporter commented 9 years ago
Same issue here:

I'm sure it's not the internet connection. The stream runs for about 15-18 
minutes and then fails. When you try to resume it shows constant buffering. It 
plays 2 seconds, buffers for about 1 minute, and then plays 2 seconds (etc).

I've had this problem on a machine running Windows 7 (32bit), XBMC 12.1 and the 
latest release of the plugin. I've reverted to XBMC 12.0 (which I run without 
problems on another machine) but this did not help at all.

Any suggestions?

Original comment by gijswob...@gmail.com on 20 Apr 2013 at 9:39

GoogleCodeExporter commented 9 years ago
We are working on a solution upstream (@xbmc). Only workaround for now (should 
be) using the mobile streams...

Original comment by arnov...@gmail.com on 20 Apr 2013 at 12:14

GoogleCodeExporter commented 9 years ago
I am running the XBMCbuntu 12.2 test build now (built 17th of April) and still 
experience the problem that uitzending gemist streams (sesamstraat in this 
case) stop after 15 minutes. This applies to the mobile channel as well. 

Original comment by geert.gr...@gmail.com on 20 Apr 2013 at 6:48

GoogleCodeExporter commented 9 years ago
@arnov...great news...
I'll try the mobile channel tomorrow.
I did already test the mobile channel with skipping ahead in the stream.
If I do that I also have the buffering/drop audio for a few seconds issue.
Also see issue 424 on this forum.
Any comment on that arnov?

Original comment by patrick....@gmail.com on 20 Apr 2013 at 7:48

GoogleCodeExporter commented 9 years ago
May I suggest a workaround for the time being?

Recently discovered the function "XOT:Download Item" in the context menu.
It will give the user the option to download the linked video after which it 
can be watched flawlessly.
Download speed is pretty close to my internet bandwidth limit. (25min video = 
200MB downloaded in 30 sec.)

Drawback is the extra steps to take which could be reduced significantly with 
Bas Rieter's help.
1> Currently download location always opens up in folder: 
    "/Users/<username>/Library/Application Support/XBMC/userdata/addon_data/net.rieter.xot/cache/" 
   Would be great if another destination can be preset in the preferences.
2> the filename extension is lost during the download process. Renaming is 
necessary before XMBC can
   recognize the file as a video file. adding the ".mp4" extension did the trick for me.
3>I can only download to mounted drives. Not a big problem for me (running on 
OS-X, but for users with an 
   apple TV local downloads could become a problem . Some sort of SMB support is desirable.
4> combine all of the above in a context menu function "Download & view" in 
once.

I do realize that this a bit off topic and is more a feature request than a bug 
report, but it could be helpful to those who read the issue. 

Original comment by tijnep...@gmail.com on 27 Apr 2013 at 1:55

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Hi,

great to hear you are already working on a solution! I was very happy when I 
found your addon and I hope it's not too hard find a fix since besides the 
issue it works great on my little pi!

I don't know how far you are in resolving the issue, but maybe my info can help 
a bit - I also attached a snippet from the xbmc.log that appears when the issue 
is happening. 

My experience is pretty much the same as mentioned:
The stopping or staggering issue always happens with uitzendinggemist programs 
(not the mobile ones) after 10-14 min. Just for the record: I tested it with 
episodes from "De rijdende rechter" en "Keuringsdienst van waarde" at 3am, 6am 
and 8pm. When the playback stopped and I got back to the menu, I resumed the 
playback from the bookmarked position. 

A couple of things I noticed:
- when it starts playing again it shows subtitles nevertheless it started 
playing without them, since I unset subtitles for all videos. 
- if I pause the video I notice it is buffering, yet if I hit play again it 
staggers or exits and the buffer seems to be gone.

Things I was wondering about: 
- the log entry looks like the plugin or a part of xbmc are actually 
restarting, is the issue connected to problems with pausing/resuming after 
crashing and crashing because of that again? 
- I remembered a similar behaviour with machines that are low on memory and/or 
cpu power when using Minitube. Is xbmc maybe just transcoding the 
uitzendinggemist flash content and has to stop since the memory is full or 
something is just crashing since the transcoding can't keep up?

Would be very nice to hear how far you are with fixing the issue!

Original comment by howtoeve...@gmail.com on 30 Apr 2013 at 1:56

Attachments:

GoogleCodeExporter commented 9 years ago
I have a feature that does exactly that. But I do want the end-user to be able 
to toggle it instead of forcing it to behave like that. 

So I will create an option for it in the settings of XOT-Uzg.v3. I am finishing 
up the 3.3.5 version and it will be in that version.

Original comment by basrie...@gmail.com on 30 Apr 2013 at 3:03

GoogleCodeExporter commented 9 years ago
I completed (I think) this feature. If there is a volunteer that wants to test 
it, please let me know at uitzendinggemist.vx [@] gmail [dot] com. Please keep 
in mind that you will get a beta (almost release though) version, that will 
need to be deleted manually in order to get the actual 3.3.5 via the repository.

Original comment by basrie...@gmail.com on 30 Apr 2013 at 6:20

GoogleCodeExporter commented 9 years ago
I'm experiencing similar issues. I just installed the latest Rasbmc and the XOT 
addon and am watching Uitzendinggemist. First session stops halfway and if I 
resume it's constantly buffering. I just started an other session (different 
stream) and this also stopped halfway. After I resume it constantly buffering. 
I installed iptraf to measure the bandwidth and noticed that when before the 
halfway stop it's at 4Mbit but after I resume it's at 10Mbit.

Original comment by aloons...@gmail.com on 4 May 2013 at 8:47

Attachments:

GoogleCodeExporter commented 9 years ago
Like I already mentioned: I implemented a temporary work around in the next 
version for this. 

Did anybody test it on 12.2 on rPi? I myself did not get to it yet.

Original comment by basrie...@gmail.com on 4 May 2013 at 9:15

GoogleCodeExporter commented 9 years ago
> Did anybody test it on 12.2 on rPi? I myself did not get to it yet.

Not sure if you refer to the original bug or to the work around.

I have an rPi model B (512MB) with openelec 3.0.2 (frodo 12.2) and the problem 
still exists there. Once there is a buffer underrun, the buffer does not fill 
again. If I press pause it does fill again, but it clears as soon as I press 
play.

I'd be happy to test the beta 3.3.5 if you still need testers.

Original comment by Peter.Oo...@gmail.com on 5 May 2013 at 11:12

GoogleCodeExporter commented 9 years ago
I also tested this on my rPi this morning (without the 3.3.5 version) and 
indeed no fix for this issue. So 3.3.5 is almost finished and will have the 
workaround. 

Original comment by basrie...@gmail.com on 5 May 2013 at 11:45

GoogleCodeExporter commented 9 years ago
Implemented in XOT-Uzg.v3.3.5

Original comment by basrie...@gmail.com on 9 May 2013 at 2:14

GoogleCodeExporter commented 9 years ago
I've the same problems with uitzendinggemist.
Watching for a good 24 minutes en then buffering the rest of the time.
Pause 5 minutes and for watching 1 minute again , cache empty ;(
Download works ok, but that's not streaming is it ;)

Original comment by spijker9...@gmail.com on 10 May 2013 at 5:36

GoogleCodeExporter commented 9 years ago
The download is just a workaround until it is fixed in XBMC.

Original comment by basrie...@gmail.com on 10 May 2013 at 5:37

GoogleCodeExporter commented 9 years ago
cool, great plugin btw ! , love it.

Original comment by spijker9...@gmail.com on 10 May 2013 at 5:44

GoogleCodeExporter commented 9 years ago
FYI: We just committed a fix in mainline to remedy the actual problem.

Original comment by arnov...@gmail.com on 10 May 2013 at 5:51

GoogleCodeExporter commented 9 years ago
That is really good to hear Arnova. Do you perhaps have the commit ID? And will 
it be in a possible 12.3 (if it will ever be there?)

Original comment by basrie...@gmail.com on 10 May 2013 at 5:53

GoogleCodeExporter commented 9 years ago
Well it's https://github.com/xbmc/xbmc/pull/2229 which consists of several 
commits. I doubt this will be backported to 12.3 since the code is non-trivial 
and needs further testing.

Original comment by arnov...@gmail.com on 10 May 2013 at 6:16