4 replies to this topic

[orizatriznyak]

Hi there!

 

I have been using Openpli images for years on my Vu+ boxes. I have had a problem with my iptv source on my Zero. It is a TvHeadend server with a DVB-C source.

The stream suddenly stops completly for about 8-10 seconds, then it continues with heavy glitches from the stopping point, so there will be a 8-10 sec delay to the source.

If I change channel forward and back, stream runs again for a while without problem. While this happens, there is absolutely no problem on my android TvHeadend client, or on my other STB (Vu+Duo4kSE with Openpli 8.3) on the same channel, so there is no network issue, and no problem on the server side. Typically this issue occurs on channels that have higher bitrate (>10Mbit).

I have also tried to change the player to servicemp3 or exteplayer3 but is has no effect to the problem. I am not sure but it seems this issue comes more often when the uptime is longer. Absolutely no problem with my SatIP source on high bitrate channels.

Any idea?

 

 

 

[mimisiku]

Yes, the VU+ Zero has very little RAM,a 100 Mbit LAN and runs at a low speed! With the current HD standard it is simple too weak! You might use transcoding from your other box and reduce the format and bitrate.. Or buy a VU+Zero4K

[orizatriznyak]

I understand your point but why there is no problem with satIP client (at the same or higher bitrate)? I constantly run an icmp check to the server every sec. No unreachables, or high latency while the problem occurs. I also did tests with other type (basically older) of receivers like Vu+Duo (Openpli 8.3) and DM800HDSE (Openpli4). No problem on these receivers.

[WanWizard]

You can't compare the two.

 

SatIP is a constant realtime stream of 188 byte packets that are processed realtime or dropped. So theoretically you only need 188 bytes of memory to buffer the stream.

 

HTTP streams need a lot more memory for buffering, and with serviceapp even more. The problem is compounded by the fact no box supports scatter/gather, which means the network driver needs to allocate memory in a single block. Those are scarce to begin with on a box with not a lot of memory, and this gets worse when time goes on, as free memory blocks are scattered due to constant allocation and deallocation.

 

The reason is that this is not a realtime stream, the client says "give me the data", and the server will respond with "here you go" as fast as it can and for as long as the client allows it. This means the client receives more data, and faster, then it can process (which needs to be realtime).

 

You might try to see if adding a swap file brings some improvement.

[orizatriznyak]

Ok, I'll give it a try, thanks!