Yes, I am wait logs from last prerelease.

Prog wrote:Yes, I am wait logs from last prerelease.

Hi,

I resend to you the last losgs... now a new one with full m3u file:
http://pastebin.com/TeN6ZUZR

I hope you can fix soon the problem to show at minimum one channel!

Look in email. Need logs from last version. And try manual scanner.

Do you receive my email? Do you test last version?

Prog wrote:Do you receive my email? Do you test last version?

Yes, but no pre-release version "b" exists!

Here my suggestion for solve problem A: play one RTSP source...

1) Read http://juliensimon.blogspot.com.es/2008 ... h-vlc.html
2) Save a full TS captured from any transponder to your harddisk
3) Use VLC to stream the TS using RTSP
4) Create a M3U file with only one rtsp enty
5) Debug your program

I hope with this you can complete the play of one channel. Remember: my device is using live555 library, as VideoLAN and several other Sat>IP servers.

For solve problem B: channel change or transponder scan...

When ProgDVB can play one RTSP source, I'll try to use a network sniffer to debug some Sat>IP software that can do the channel change without problems. I feel the problem is send commands in different order to shutdown streaming of the channel before ask for another one.

Regards.

Hi Prog,

Good job! After check pre-release "7.05.6a" x64 version:

- Setting manually the m3u file in the config window of "DVB over IP" device: OK (now works! great!)
- Scanning of channels of "DVB over IP" device: OK (but very slow: 600 channels in more than 2 hours, sometimes minutes to scan one channel)
- Channel list for "DVB over IP": OK (some channels detected as radio or data, even only video channels in the "ServiceList-5-Video.m3u" file)
- Play a channel: Don't work.
- Change channel: Several times don't work!

I explain the troubles:

1) Show/play channel errors: When I open a channel the video has errors (several) and no audio. I try to enable option "Open channels without playback". Then I record a channel and I play it with VLC. The result is a choppy video/audio. Messages indicates "discontinuity errors". In the "Input Traffic Information" window of ProgDVB the Traffic/Minimal lost shows around 35% of lost IN ANY CHANNEL. Conclusion: The RTSP device is losing packets.

2) Channel change: When I change a channel in the channel list sometimes after the change ProgDVB shows "Connecting..." then "Error!" This is when channel is in another transponder. Only after serveral time I can change to another channel. The problem seems to be related to the common trouble of shutdown current channel before request for new one. This problem appears from time to time, not always (but often). Also, ProgDVB is not retriying to connect to the channel when it fails.

Please Prog, can you fix these problems? What you need from me now? More logs or TS records?
Regards.

1. RTSP is quite slow protocol and that (RTSP in your device) is big hardware problem of your device. But why 600? Usually satellite gave ~100 transponders. Also check addition delay in Options->Scanner. You must set 1-2 seconds if some channels not detected or detected as data.

2. Playback looks like my bug. Need logs.

Prog wrote:1. RTSP is quite slow protocol and that (RTSP in your device) is big hardware problem of your device. But why 600? Usually satellite gave ~100 transponders. Also check addition delay in Options->Scanner. You must set 1-2 seconds if some channels not detected or detected as data.

2. Playback looks like my bug. Need logs.

Hi Prog,

Logs at http://pastebin.com/sHpeMbdd

Comments:

1) Related to packet lost: no relevant info in the logs. Only always around 34-37% lost... in ANY CHANNEL. Can I enable more verbosity for checking packet continuity?

2) Logs are created as this: I open ProgDVB, automatically selected last channel, try to play this channel (corrupted image), after 5 seconds I close the program. You can read the logs... no interesting info on them.

3) Slow channel scan: With other software typical scan time is around 30 minutes for full Astra scan. Nevertheless, this scan is using tunning/filter commands, not using the m3u file with channels scanned by the stb. I suggest to minimize the time you're doing the scan: when you use the programm tunning (with RTSP) the stb filters the TS and only send pids for this channel (but all pids, not only video or audio, it includes PAT, PMT, EIT, SDT, CAT, etc.). So you don't need to wait seconds to discover the pids of the channel, only after some packets you have the relevant info. Please, can you add an option to tweak the time to scan a channel?

4) Improve channel scan: As the m3u has a list of channels, why not include an option to start scanning from a specific channel number? If the list don't changes, and you have stoped previous scan, if you can start from the last scanned channel you can go fast. You agree this?

5) Errors when changing channel. My opinion is solve this issue after fix the packet lost.

I hope next version can play SAT>IP channels!
Thank you for your support.

Additional info:

LAst logs don't include any scanning process, but one shot of scanning logs:
Interesting part is "Timeout on reading"... Can be related to packet lost?

"Timeout on reading" mean no data from network very long time.

How I can download pastebin.com? Please send me in attach.

ps: ProgDVB scan dvb channels ~14 yeas. And do this quite good and fast. But RTSP is problem...

Prog wrote:"Timeout on reading" mean no data from network very long time.

How I can download pastebin.com? Please send me in attach.

ps: ProgDVB scan dvb channels ~14 yeas. And do this quite good and fast. But RTSP is problem...

Hi,

LOGs in pastebin are ZIP in UUENCODED text format. Nevertheless, here is the last log as attachment...

Related to slow channel scan: Think that each m3u entry (channel) is consuming 20 seconds in the scanning process... and my m3u file lists 1190 channels (calculate full time!). And the current version crash after 1 or 2 hours... I can't full scan the satellite. Please, add an option to start from any point, not the first one in the list (at minimum with manual scanning).

More about when you scan: you scan the full transporder (as the PAT) indicates, but only one channel not filtered is in the TS. If you don't short times and scan for all channels you waste time. Or not?

Regards.

Do you have m3u list for channels(~1000) or for transponder (~100)? If for channels then can import that list without scanner over IPTV Client

Prog wrote:Do you have m3u list for channels(~1000) or for transponder (~100)? If for channels then can import that list without scanner over IPTV Client

Hi Prog,

I'm confused!
You have the full m3u in the logs3 (Transponders\IPTV\ServiceList-5-Video.m3u)... I re-attach in this post.

Nevertheless, even if this list has 1190 video channels you need to scan them because it's a TS with filtered pids (including PAT, PMT, CAT, EIT, etc.). I don't recommend to bypass scanning, but improve the task. When you receive one packet of video and one packet for each audio channel you can stop the scanning process for the channel... because in the TS no more channels found (because TS is filtered). Remember: ONLY ONE CHANNEL PER TS.

It is not important for scanner one channel or not. PAT table include this information. But not need scan this list. ProgDVB must open that over IPTV Client (import without scan mode)

Prog wrote:It is not important for scanner one channel or not. PAT table include this information. But not need scan this list. ProgDVB must open that over IPTV Client (import without scan mode)

Hi Prog,

I don't agree this! First, IPTV client don't work with RTSP. Second, when you call some channel using an http request from m3u file, you enable the streaming of a TS with all pids related to this channel. However, you don't have the info about the pids in the channel decription in the m3u file. For this reason you need to "scan for the channel". But when you scan for a transponder you are parsing the entire PAT table. This is the same table for a filtered TS, but in a filtered TS you only have one video pid and the audio pids for this specific channel (plus other additional pids: EIT, CAT, etc.). So, the correct algorithm in this particular case can be:
I'm sure that with this workaround the scanning process will be more fast!

Related to the current bug of packet losts, you will fix it?
Thank you for your good job!

ProgDVB receive one scream. If server send all pids in stream then you can scan only ~100 transponders. If only per channel then you can open without scan.
But that process not depended from client software and from scanner.