RTP mode important also. You can try change to "enable" in IPTV Client properties.

Prog wrote:1. Test RTSP/TS from VLC from file and not have any problems.
for example vlc -vvv test.ts --sout=#rtp{sdp=rtsp://:8554/testTS} :sout-keep

Hi Prog,

I do another test, with this vlc command: So I change the m3u file for this channel.
Notes: Without "mux=ts" a VLC client can't open the channel. I try "sout-all" for not filtering the TS.

The results with this setup:

1) VLC: plays the channel.
2) ProgDVB: scanning sometimes detects the channel, sometimes not. When I try to play channel it crashes (logs attached).

I'll try to provide to you a capture of the TS from my device. Stay await!

Hi Prog,

Here attached a TS record. I do the recording using FFmpeg with this command: I provide also the LOGs from FFmpeg for your convenience (some packet lost detected at the begining).

With this capture I do this tests:

1) VLC: plays the file
2) FFMpeg: plays the file
3) ProgDVB: Open file... crash
4) FFMpeg streaming the file to udp multicast and receiving using ProgDVB: crash

I hope you can do more tests with this file.

Regards!

Note: I also checked the file with TSreader Lite and no problems found!

Try "b" prerelease. And send me logs of 3-4 channel with 10-20 seconds on every channel.

Prog wrote:Try "b" prerelease. And send me logs of 3-4 channel with 10-20 seconds on every channel.

Hi Prog,

You're the best!

Now packet lost is fixed! Great! Now I can show channels from my stb in ProgDVB!

Nevertheless, the problem with channel change continues: The logs show that when you request a new channel the response is "503 Service Unavailable". I attach the logs of this sequence: open ProgDVB, play one channel (ok), change to other (wait, error), change to other (wait, error), etc... finally close. I take into account that after you send the TEARDOWN command, no response from the server is showing in the logs. Perhaps you need to wait for the response before send other commands.

Regards!

Hi Prog,

More troubles!
With some channels, ProgDVB is always in "Analysing..." mode... I attach logs.
The test I do: Tune Euronews... no go (selected from an already channel list); manually scan "rtsp://192.168.210.181:554/programID=5259265" (mapping to this channel)... this found channel name "TV Service 31220" (this is the SID of the channel), and when I select this channel... "Analysing..." forever. Moreover, in this case "Minimal lost" shows ~2.5%

UPDATE: If I double-check over the channel, sometimes goes right!

I feel someother thing in the receiving code is causing troubles. This trouble ins't only with this channel, with several others the same issue.
Obviously, for my check I also open the channel using vlc rtsp://192.168.210.181:554/programID=5259265 (and plays fine).

I hope you can fix soon!

Hi Prog,

Annoying bug! If I open ProgDVB without my BDA device enabled (and configured) then the Plugins (Multidec API) aren't loaded. Also, if I change a channel from the BDA device to "DVB over IP" device, all plugins are removed (Multidec, plus Services: TS Recorder and Prog Media Home Server). Please, remove this annoying limitation! "DVB over IP" devices are like any other DVB devices!

I feel this "bug" it's very simple to fix!
Thank you for your hard work.

It is simple but your device is not same like DVB.
1. It repack traffic and I am not sure about CI streams in result.
2. Addition delay for traffic. Impossible use sharing with addition 1-3 seconds delay.

evarost wrote:
With some channels, ProgDVB is always in "Analysing..." mode... I attach logs.

What different between "good" and "bad" channels?

Prog wrote:It is simple but your device is not same like DVB.
1. It repack traffic and I am not sure about CI streams in result.
2. Addition delay for traffic. Impossible use sharing with addition 1-3 seconds delay.

Hi Prog,

Related to support Plugins: For sure you can do that. This device is a REAL DVB device. You receive the FULL TS (filtered without non related pids). The device don't "repacks" anything, it only filters pids... no more, no less! At time, you're not using pid commands (as the full SAT>IP protocol specifies), but the result is the same: you receive all TS packets filtered with all pids of the channel. No differencies at all. So, you don't have any fundamentation to not support this. Moreover, this is the reason to use ProgDVB and not other software for view channels with a SAT>IP server. Your software will be the first (and at time the only one) on Windows platform to support plugins with a SAT>IP server.

Please, can you try to enable this?
Thank you!

Prog wrote:

evarost wrote:
With some channels, ProgDVB is always in "Analysing..." mode... I attach logs.

What different between "good" and "bad" channels?

Ummmm....

At time, this problem minimizes setting 3000ms for delay for channel change (TimeForOneChar option) and using "update" in channel properties with manual adjusts (sometimes video pid is "0" and I need to correct this). But the real problem is the scanning. Now, the scanning process is a pain. The problem is excesive slowness (20 seconds for each channel) of the process. But you need to do it, because you need to read all related pids (video, audio, PAT, PMT, EIT, SDT, CAT, etc). Remember, you are receiving a normal DVB-TS filtered by the device (as a real tuner), not with a buffer in memory, but with a stream over the network (transported using RTSP protocol)... SAT>IP are real DVB tunners (never repacking the TS).

So, I suggest this:

Add one option for "DVB over IP" devices to "import channels without scanning" (like similar for IPTV), but save internally in the channel list one option to detect if the channel is already scanned or not. Then when you select to play one channel, if it's the first time, you do the scanning process. After that, you have the full info of the channel, so don't need to repeat another time. This is different (as my understand) that on-the-fly pids discovering that you're doing with IPTV channels. Here you need to do a full channel scanning, but only one time. The difference is do it only when you select a channel and not when a full scanning of the entire m3u list. Can you try, please, to implement this?

Another suggestion for fix problems with channel change is repear the TEARDOWN command, or wait more time (perhaps a config value for delay) for receiving the response. I feel that is a huge requirement to close a channel before request for another.

And, please, remember that the final goal is support SAT>IP like BDA devices. We like to use plugins, pid recording and Prog Media Home Server.
I spend several time to check your software and prepare logs. I hope you can improve your beatiful software wihtout much effort.
Another time: Thank you!

1. About pids. Check ECM value in channel properties and in File->Input traffic->All pids. But problems in delays in any case. I am not like add function if not sure in 100% stability. Do you like crash every hour?
2. Traffic remuxed, because only one channel in place of 10-20 channel per mux in DVB.
3. Scannner not need for your device and you can use IPTV Client without any problem. I am not can repeat that in every message :-/
4. About TEARDOWN, I prepeare version today or in near days.

Prog wrote:1. About pids. Check ECM value in channel properties and in File->Input traffic->All pids. But problems in delays in any case. I am not like add function if not sure in 100% stability. Do you like crash every hour?
2. Traffic remuxed, because only one channel in place of 10-20 channel per mux in DVB.
3. Scannner not need for your device and you can use IPTV Client without any problem. I am not can repeat that in every message :-/
4. About TEARDOWN, I prepeare version today or in near days.

Hi Prog,

First of all, thank you for your time!
I try to answer your comments (in different order):

3) I already checked the last version using IPTV Client. The result is similar, except that I only see video+audio. Not all pids.

4) Ok. I'm happy to listening this. I'll check this version when you publish it.

2) Traffic "remuxed" != "filtered". Please, answer this: What you receive from the tuner when you select some pids, the full TS? No, the filtered TS. Here it's the same. Using "pid" commands over the RTSP channel you can request for a full TS (yes! all pids), or filter it. Moreover, the SAT>IP protocol specificies to use multicast, and users can add (or remove) pids to some "shared" stream. Clients, receive all requested pids or more. So, the "program" command of SAT>IP is a more simple function: you receive TS with all pids of this channel, only pids of other channels in the same TS are filtered to not waste network bandwith. So, please, I understan your view. And I share you view. But, this protocol not is a IPTV protocol. Is a network tuner specification. It has identical functions that any DVB API (BDA, LinuxTV, etc.). The only difference is the network and shared users.

1) About Pids, you are rigth. I attach two screenshots of the window "Traffic information" that shows pids. Please, see images of FTA and non-FTA channels. As you can view, ECM pids aren't in the TS. Yes, this is a trouble. Nevertheless, using SAT>IP "pid commands" you can add any pid that you like. You only need to use correct commands (and the box do it). But, first we need the correct graph running to process packets. After that, the only task to do is add the pids.

1) Finally, related to crashing, you don't need to care about delays. The SAT>IP server don't use caching at all (uses udp, not tcp), and send TS packets when arrive, so low delay (similar to any USB tuner). In the client side, you only need to reduce buffers from the network (internal buffering after receiving is another thing). So, the real delay can be around hundred milliseconds. When I use the "oficial" Windows SAT>IP software (that uses "pid commands") published (and sponsored) by SES, called "DVB Viewer Lite" (http://www.satip.info/products/Software), I can do a channel change over different transponder in less than a second, more fast than with an ancient USB 2.0 DVBS tunner that I have. So please, don't think that the network is slow.

Regards.

Hi Prog,

If you prefer to implement a full client of SAT>IP specification, here a simple example of "pid commands":
http://www.vdr-portal.de/board16-video- ... ost1195907

I'm sure that after implement RTSP client functions will be very easy for you to implement the "DVB over IP" module that implements "pid commands" and not the "programID" mode.

Regards.

1. No ECM on your picture. Then no way for plugin.
2. Per PID mode looks like very slow. Because usually software (and plugins) send commands for open/close by one PID. Not all pids like in sample from you link.