41 replies to this topic

[WanWizard]

Can you define what you mean by "stream a recording from the PC to a client"? How exactly do you do that?

 

If you open a .TS file, it's the client that determines the pace with which the file is read, and buffering happens client side. If it is really streaming, the sending side determines the pace, and if there is no client-side buffering involved, any glitch in the communication will be visible...

[spock]

I just record it to the HDD of the ultimo and stream it from there (although this glitches too sometimes, albeit less, perhaps I should mention that even viewing recordings on the ultimo itself often glitches). If I move the .ts to the PC and share it from there, then there are never any troubles streaming it to wireless clients (and that's over SMB).

 

Did a fresh install without backups on the ultimo less then a week ago too, if it makes any difference.

 

edit: Still trying to get that buildroot set up, so many package sources missing, taking forever to find alternative sources.

Edited by spock, 29 May 2013 - 12:13.

[spock]

After adding the following to /etc/sysctl.conf, STB>PC stream has now been glitch free on a high bitrate HD channel for almost 10 minutes.. praying this was some sort of fix.

net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.core.netdev_max_backlog = 5000

Although dmesg now spit out:

------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x488/0x494()
NETDEV WATCHDOG: eth0 (bcmemac): transmit queue 0 timed out
Modules linked in: ipv6 fpga_directc(P) brcmfb dvb_bcm7413(P) procmk
Call Trace:
[<8056b1bc>] dump_stack+0x8/0x34
[<8003234c>] warn_slowpath_common+0x78/0xa4
[<80032400>] warn_slowpath_fmt+0x2c/0x38
[<80473e68>] dev_watchdog+0x488/0x494
[<800423d8>] run_timer_softirq+0x148/0x284
[<8003a540>] __do_softirq+0x104/0x1d4
[<8003a910>] do_softirq+0xa4/0xac
[<800026f0>] plat_irq_dispatch+0xa8/0x104
[<80004c84>] ret_from_irq+0x0/0x4
[<80004ec0>] r4k_wait+0x20/0x40
[<80006d9c>] cpu_idle+0xa4/0xac
[<806a4934>] start_kernel+0x3a8/0x3c8

---[ end trace 2bbc81ac279ea4c5 ]---

Edited by spock, 29 May 2013 - 12:33.

[WanWizard]

Opening a file over SMB is not streaming, that's why I asked. In that case the client has control, and a lot more in terms of buffering is possible.

[spock]

For 30 minutes now after chancing sysctl.conf I have no glitches. Bit puzzled over this.. VLC buffering is even at minimum (was hoping to trigger problems quickly).

Edited by spock, 29 May 2013 - 13:12.

[MiLo]

After adding the following to /etc/sysctl.conf, STB>PC stream has now been glitch free on a high bitrate HD channel for almost 10 minutes.. praying this was some sort of fix.

net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.core.netdev_max_backlog = 5000

Start by explaining why you set these values. What is the problem and why is this a solution? And what is it that you want us to do?

[spock]

Well it seems changing those settings in sysctl.conf (found from Google) has fixed it, no glitching for almost an hour now. Unless it's just working unexpectedly well currently, although I've never seen it run this long without breaking up.

 

Probably most of them are superfluous, but streaming is working great now.

[spock]

And then the problems came back, heh. Atleast after freezing it recovered now.

 

Sorry if I can't be more helpful. It's probably just the VU+ and their crappy drivers screwing me over again, seeing how I'm the only one experiencing this.

Edited by spock, 29 May 2013 - 14:01.

[spock]

It just seems to be a matter of time, the more buffers the longer it takes for the problem to show up.

[spock]

I just tested with official vu+ software, and this problem doesn't exist there.. so it's obviously something on their end.

 

Just another reminder to never buy vu+ hardware again.

Edited by spock, 29 May 2013 - 16:46.

[WanWizard]

Meaning you have the same issue with the VU+ image?

[spock]

No, VU+ image didn't display any problems during 1 hour of testing. Not long enough test perhaps, but it was completely unmodified settings when testing.

 

But with the sysctl.conf changes, openpli image didn't show any problems up until one hour either, where it slowly started to display same behaviour again. Then again it could just be that I'm having a good day and sysctl.conf in practice did nothing...

 

It feels like some counter/buffer is slowly overfilling (for the lack of better wording as im not a programmer). If I put larger tcp receive/send window, etc (like sysctl.conf above) with openpli, then it will take longer for the problem to show up, it's pretty much the only conclusion I have made so far. Similar was seen with samba on the stb, 4-5MB/s jumped up to 10-11MB/s when adding send/receive buffers.

 

Still trying to make my own build of openpli with more/larger buffers, but I think the git timeouts I replaced/fixed with normal files broke the build in the end, so I've got to start from the beginning there. There really are a lot of git timeouts during building/preparing.

Edited by spock, 29 May 2013 - 17:44.

[WanWizard]

You have to be careful with large buffers on a VU+. Their drivers are crappy, and contain memory leaks, so over time, less and less memory will be available.

 

Perhaps something else to test: do you see a difference between a box that just has been rebooted, and one that has been running a few days?

[spock]

For the streaming issue no, it doesn't matter if the box is freshly rebooted or not. To playback a recording on the other hand, on the STB that is, then if the box has been running for a few days there will always be glitches..

 

You think my problems with streaming could go away if I got myself an ET9xxx box? Since this VU+ and it's drivers have given me nothing but headaches since the day I got it.

Edited by spock, 30 May 2013 - 13:37.

[WanWizard]

I'm not sure that will help, I'll check tonight if I see any difference between the VU+ and the ET9000.

[spock]

I borrowed my friends DM500HD out of curiosity, and it streamed flawlessly for over 4 hours with openpli image. Not a hickup.

 

Would be nice to hear how it went with the ET9000 for you.

 

My VU+ Ultimo is going out the window! Or maybe I can sell it to some poor soul.

 

 

edit: And my modified build for VU+ Ultimo showed no changes.. although I'm not sure I got the code in to the right place (demux.cpp). Anyway I think I'm going to give up on VU+ and their boxes now, enough is enough.

Edited by spock, 31 May 2013 - 02:12.

[Rob van der Does]

I am using both the Ultimo and ET9200 to stream to and from other boxes, and I never had any issue.

[WanWizard]

I ran a test here with the VU+ and the ET9000, both streaming the same channel, side-by-side.

 

When I had pixelation due to a drop in wifi connection quality, both streams had it at the same time, and for for the same duration.

 

So it seams that the issue is indeed related to the quality of the connection, and not really related to the box itself...

[spock]

I give up...like trying to explain myself to a wall.

Edited by spock, 31 May 2013 - 17:56.

[spock]

Although openpli seems to regard this as irrelevant, I've made some further research into resolving my issue with streaming breaking down on the Ultimo.

I found out enigma2 can record to NAS / network devices without hickups, due to more buffers. But while directly streaming (VLC, WebIF), there are less buffers available in e2, and they tend to overflow, causing enigma2 to bail, and for some reason if this is allowed to continue, i.e. if not restarting the stream, client starts seeing corrupted packets. HD is more prone to errors then SD, but it happens with SD too. MPEG2 or MPEG4 coding seems irrelevant.

[eFilePushThreadRecorder] Warning: All write buffers busy

For anyone who wants to reproduce the issue with a VU+Ultimo, just put up a crappy link, pull ethernet between PC and VU directly (or switched) and force it half-duplex 10Mbit, or use some a poor WiFi signal and you'll see the problem starting to surface pretty quickly. And just like that it's fine for a while, but eventually it breaks up and e2 can no longer recover, and all the client will see is corrupted packets). If you run e2 manually you'll see the error messages, if you google them you'll find other images/teams have a few similar reports, but there are indeed not many. I even found a post of one dev trying/suggesting to rewrite the whole buffering behaviour of e2 streaming.

Just for reference, this problem happens to me even with CAT6A (yes, I bought new cables only for testing this) ethernet cable straight between PC and VU, or the same with PC > 1GBit switch > VU. I've also tested two different Gbit switches, always making sure the Ultimo is in 100Mbit full-duplex. It will just take much more time to show up then it does on a poor connection. A glitched higher then normal ECM or a slight satellite signal issue, such as those damn pigeons landing on the LNB for example could be a likely culprit to initiate the problem in e2 too I believe. I've also tried streaming to another PC to rule out bad network drivers/port in the PC. The end sum is that the e2 stream just will not recover on it's own, it has to be restarted manually (in VLC press stop and then play).

And for additional reference, here is the output of "ping -f -s 1500" to the box from my PC over a 1 hour session, normally a stream would have broken up around 4-5 times during this if I was streaming over the WiFi bridge, with ethernet perhaps once or twice.

 

ping -f -s 1500 192.168.x.9

PING 192.168.x.9 (192.168.x.9) 1500(1528) bytes of data.

.^C

--- 192.168.x.9 ping statistics ---

5293617 packets transmitted, 5293616 received, 0% packet loss, time 4892110ms

rtt min/avg/max/mdev = 0.174/0.821/24.798/0.090 ms, pipe 2, ipg/ewma 0.924/0.809 ms

Although I'm no programmer I decided to take the plunge into some amateur coding/fixup mainly in demux.cpp, slightly changing buffering behaviour and increasing streaming buffers to try and prevent buffers from overfilling and the stream from breaking. And now it seems I've solved my problem with the VU+Ultimo, it's happily streaming for hours on end without hickups. I might have introduced other problems in the code as I'm not really sitting on the expertise that the openpli devs do, but I haven't seen any new problems yet. My gut tells me it's no real solution though, proper behaviour should probably be that e2 restarts the stream itself if it runs in to buffer overflows, or maybe it already does this, or tries - but fails.

Since my problem is solved you now have one less annoying forum member. But perhaps I've given you something to consider before yelling network problems. Unless we perhaps wan't to blame the ethernet port of the Ultimo itself, or it's drivers.

That'd be all. Many thanks for the work with openpli over the years, it was always my number one choice, ever since e1 and jade!


Spock, signing off.