Re: SAT>IP Protocol support

#183
Hi Prog,

WOW!!! YOU'RE THE BEST!!! The version v7.07.5 has enabled PMS for SAT>IP devices and it's working!!! Thank you!!!
:D :D :D :D :D

You have now good SAT>IP support in your software. I found it's the best Windows software for DTV.
Nevertheless, some minor suggestions/bugs to fix:

1) My first problem is one annoying problem with quality. I explain more. When I use other software (like official SAT>IP client from SES) I don't show any errors with the image, but with ProgDVB each 3-4 seconds, some minimal error appears in the image (or sometimes the sound stops for miliseconds). I feel that some RTP packets are lost when you receive the TS. It's possible to incorporate some buffer or realtime thread to receive data? I suggest to you to incorporate in LOGs printing all discontinuity errors detected in the TS received. This my high priority bug to fix.

2) When you select "EPG update" using the SAT>IP device I found that you request the full transport stream. This wastes resources. I suggest to request only for pids that you actually need to receive. This speed up the EPG refresh (now for full ASTRA scan are 40 minutes!), and reduces errors (with heavy transponders the full TS is impossible to receive without errors).

3) Another suggestion: It's possible to add a memory buffer for the PMS? With an unpowered SmartTV hardware I can receive the stream over HTTP, but sometimes when retransmissions occurs the stream received has some discontinuity. I feel that this buffer can increase the resilence of the stream with clients, and more for wireless clients.

I hope you accept these suggestions!
Regards.

Re: SAT>IP Protocol support

#185
Prog wrote:1. File - input traffic- packet lost?
Hi Prog,

Related to problem 1: Local viewing don't have more errors (or minimal more) than with other SAT>IP software. But your software, in "input traffic - packet lost" always increments the value (around 1.2%). Can you enable more debug to check this? This value isn't consistent.

Related to problem 3: More problematic is the PMS http streaming. Using one HD channel if I play the streaming using VLC in the same machine, sometines errors found (play graph in ProgDVB is disabled); not many, but some. But it I play with a SmartTV (wire Ethernet) the stream goes but after some seconds. I feel that you need to create a BUFFER for the HTTP Streaming, in acordance of the bitrate. No problems with SD channel, but HD have troubles. Can you do something?

Thank you for your great work!

Re: SAT>IP Protocol support

#187
Prog wrote:If traffic damaged then still bad after server.
Looks like some problem with rtp. You can try open same transponder over http/ts. Http alwas more stable then rtp (on phisical level)
Hi Prog,

Sorry, it's my fault! After some more exhaustive testing, the problem is my system. Now, no traffic erros at input (from the SAT>IP server to ProgDVB), only sometimes minimal glitches. In the HTTP streaming output of the PMS, also no problems... in local view no errors at all.

Nevertheless, still some suggestions:

1) When do the EIT scaning, please don't request the full TS. For transponders with >40 Mbps this is a problem for the SAT>IP server. Request only the needed pids.

2) I request one global option to set higher or lower ProgDVB priority. When I change the priority using the TaskManager I feel the system more estable.

3) Can you add one button to enable/disable on-the-fly the graph rendering? When I like to try the PMS first I prefer to show the video in the computer, and when all is going right I like to change to not render the decoding... but this implies go to options, change it, and restart ProgDVB. Can you provide this fuction?

4) Please, can you add a button in the traffic info window to "reset" values? This can be useful to do some checks.

5) When you implement the support for DiseqC for SAT>IP? It's in your roadmap? I feel it's easy to implement, so the standard supports it in the RTSP requests. Only minor changes in your code.

5) Related to autodiscovering of SAT>IP servers, I feel it has a very low priority. It's trivial for the user to put IP:port in ProgDVB, and difficult to implement (SSDP, etc.). So, I can leave without it!

Regards.

Re: SAT>IP Protocol support

#188
Hi Prog,

Another suggestion to improve robutness of PMS:

- When you do streaming over HTTP, please, do padding of TS packets (188bytes). If a choppy client is receiving data over the TCP channel, and you overwrite data in you output buffer, it's better to align bytes to TS packet bounds. If using a wireless connection and slow client, if you write/delete in blocks to the buffer -instead of bytes- I feel the client will receive less errors and resynchronize more fast.

What you think about this?
Thank you!

Re: SAT>IP Protocol support

#189
Prog wrote:If traffic damaged then still bad after server.
Looks like some problem with rtp. You can try open same transponder over http/ts. Http alwas more stable then rtp (on phisical level)
Hi Prog,

More testing.... conclusions: ProgDVB lost some packets from the RTP stream! Please, revise your code. I select "ZDF HD" in ProgDVB with SAT>IP. No other software running in my machine. No rendering in ProgDVB. Then "Minimal lost" ~0.5%, three-four losts per second. If I try "official" SAT>IP client, no lost of anything (visible, discontinuites of the TS are around 50 per 2 minutes). No problem with ProgDVB and SD channels.

If I try http stream with of the same channel, no problems.

Please, can you add some buffering when reading the UDP packets? Or try to write more logs. I'm very annoynig with this packet lost!

:( :( :(

Re: SAT>IP Protocol support

#191
evarost wrote:
Prog wrote:conclusions: ProgDVB lost some packets from the RTP stream!
Hi Prog,

After MORE testing, this sentence is FALSE. Your software is doing right. Please, don't waste time trying to fix this problem. Excuse me about this!

Nevertheless, I suggest to put a button to reset values on the window about packet lost, and insert not only the value of bytes lost, but also the NUMBER OF PACKETS (188 bytes) not received. I feel this info (number of packets) more useful.

Thank you!

Re: SAT>IP Protocol support

#193
Hi Prog,

After testing TVHeadend with SAT>IP I show some tweaks for better interoperatibility with some servers. I suggest to you to implement some of these optional features for the SAT>IP device:

- Next tune delay in ms (0-2000): With this parameter you can block very fast channel switch. Good tweak for slow servers.

- Send full PLAY cmd (yes/no): This option is for including the full list of pids in the PLAY command instead of use add-pids.

- Force teardown delay (yes/no): Interesting tweak to fix problems with servers with problems with more than one client concurrently.

I only suggest to you to think if you like to include this in your software. At time, it is working great with my SAT>IP server, but I feel that you like to improve compatibility, rigth?

Last, I like to remember to include in the traffic window not only bytes lost but packets lost (more informative).

Thank you and continue working on this great piece of software! :wink:

Re: SAT>IP Protocol support

#194
Hi,

After some time using ProgDVB with SAT>IP, I have another request/suggestion: Please, add support for a "retune" function. At some times the connection with the SAT>IP server fails (because the network breaks, some tunning error, etc.). Then I suggest to add the option of "retune" (redo the tunning call message) if no signal after some seconds. I show the problem sometimes when I change the channel, and I need to tune another channel, then return to the last one.

I hope Prog agrees this suggestion. :wink:
cron