Re: Feature Requests

Prog wrote:This mode in not correct. I am not like have option for "bad mode" :)
Hi Prog,

I can understand your point of view. But, please, let me to explain my point of view:

- When you use TS filtering tools, or TS transport protocols (like SAT>IP), you can receive an stream with more/less pids that you need. This is not a "bad mode", is only a Transport Stream with filtered pids. So, the good DVB specification defines how to work with this streams, and defines the DVB Tables to enable clients to understand the information inside the stream. Then, if you like to receive a TS with only one channel, but including the "original" tables, in this case you can receive any information related to this channel (EIT, name, etc.).

So, why not support this? In your code I feel are only two or three lines for change; and ANY client that can work with multiple programs inside a TS can understand this "filtered" stream. As an example, the VideoLAN is working in this way. I have already tested it (not with ProgDVB, obviously), and it's working. Several TS tools have just the option to enable the "table rewriting" mode, but not force to use it because are optional.

I feel that only a few number of users need this, but the effort is minimal but very useful.
But, I can understand you. Thank you in any case, and please, continue with the development of this great pice of software! :wink:

Re: Feature Requests

Hi Prog,

Related to my request about DVB-SI Tables: Can you, at minimum, write a simple SDT table? At time, without this table the original name of the channel is lost. I feel it's easy to fix this, right?

My objective is receive the current/next EIT info. To achieve this using the PMS you only need to include in the streaming the pid 0x12 (EIT), and generate (like for PAT/PMT tables) a simple SDT table with the Service_ID (to link the EIT table) and the Channel Name.

Please, can you do that?
Thank you! :wink:

PD: In the good libdvbpsi library you can found source code examples for an SDT generator.

Re: Feature Requests

Prog wrote:What device/software you use for final playback? Too many exotic request. I plan do EPG over xmltv.

Not for specific hardware/software, but several of them. Therefore, I request for "standard" support. For example, Current/Next inside the current TS. To achieve this, you only need to bypass the EIT table, and create one SDT table (like to with PAT/PMT). I feel (correct me if I'm wrong), that to copy the EIT pid is trivial for you, and create a new SDT table can be easy.

Thank for your good software!

Re: Feature Requests

Prog wrote:Standart way for you is All TS traffic. IPTV not include any EIT and ProgDVB not support that on normal level.

But do you software support xmltv?
Hi Prog,

VideoLAN supports XMLTV? NO.
Hardware STB supports XMLTV? Not many.

EIT inside the TS is the standard way for supporting EPG in any device. IPTV includes EIT in several scenarios. I know that in Russia all operators forget to use EIT, therefore the ProgDVB IPTV don't include EIT parsing. Nevertheless, I suggest (if you can) to add EIT parsing to any TS than you can receive, over DVB-x or over IPTV.

It's this feasible?
Thank you!

Re: Feature Requests

Hardware box not support EPG also. This is not IPTV and and I am not have idea how change ID of EPG in common case. For example if program for more one transponders...

But I plan do something because working on self android client.

Re: Feature Requests

Prog wrote:But I plan do something because working on self android client.
Hi Prog,

Please, re-think about the optional "pass-through" of SI tables (PAT/PMT without rewrite). If you send original tables, then the client can parse them. The bitrate of these tables is very low. You don't need to write more code, you only need to add the option to disable table rewriting. Moreover, you can expand your HTTP request to support this "on-the-fly". Example:

Current URL:

New "optional" URL:

I think this is flexible and elegant. All work is done by the client, and it needs only to parse SI tables.

Please, don't think that send a SPTS with the structure of a MPTS with filtered pids of unused programs is a breaking of the specs. The SAT>IP is doing this, and ANY client can process the TS without troubles. Example: try VideoLAN, it supports MPTS (I already test it).

You like this idea? :wink:

Re: Feature Requests

Prog wrote:1. This idea not fix problem with EPG for other transponders.
2. Bad for playback. Not all players support that becase traffic is damaged (channels in PMT/PAT but not in stream).
Hi Prog,

1) This is the behaviour of TVs! Any physical television isn't exploring other transponders to read EPG. TVs only parse EIT info when you're viewing one transponder. Please, don't think that this is stupid!

2) First: the traffic ins't damaged, the traffic is filtered! This is correct in any DTV standard. Second: You're rewriting PAT/PMT because some players need it, not because specs says this. Futhermore, any broadcaster can put ANY program inside a MPTS and not send any data of this service: this is called "not_running_status".

Please, see description of running_status parameter in SDT table: ... 10301p.pdf
Section 5.2.3, page 20

If you like to be close to specs, then pass-through all tables and patch SDT to set "running_status" to "1.not running" when you filter out the program from the TS. Nevertheless, this ins't required for the client, it can scan the programs if it likes to do.

One suggestion: Try this, you don't lose anything! :idea: