Tvheadend

Hi Jaroslav,

The cause because the "file-input" configuration isn't saved it's described in #4789.

I comment here only for reference.
Regards.

Hi Jaroslav,

You agree with this patch?

Regards!

Hi Jaroslav,

This patch is very interesting! Please, review it.
It enables the option for remapping different delivery systems. For example, from DVB-C to DVB-S.

If you're unconfortable with something, please comment about it.
I like to incorporate the option for a full remapping in the SAT>IP output, as a lot of clients only handle DVB-S.

Regards!

To be honest, I'd like to see a new tab with this mapping instead this. It will allow us also to map the mux multiple times to the SAT>IP resource space.

Jaroslav Kysela wrote:

To be honest, I'd like to see a new tab with this mapping instead this. It will allow us also to map the mux multiple times to the SAT>IP resource space.

Hi,

Thank you for comment it!

Regarding, your suggestion: it's very difficult for me to "edit" the IU. If you provide this part then I can develop the internal part. However, this patch only "extends" the current functionality. So it can be an intermidiate function previous to your wises.

Please, can you describe with more detail your vision?
Regards.

Mono Polimorph wrote:

Jaroslav Kysela wrote:

To be honest, I'd like to see a new tab with this mapping instead this. It will allow us also to map the mux multiple times to the SAT>IP resource space.

Please, can you describe with more detail your vision?

Hi Jaroslav,

I'm waiting for your response. I'm very interested in this functionality (replace DVB-C/T with DVB-S frequencies when exporting over the SAT>IP protocol). And now I'm ussing my patch with satisfaction.
However, if you disagree with my approach, please point me in the right direction.

Thank you!

Hi Jaroslav,

You don't like to comment about this patch?

Hi Jaroslav,

I'm waiting for your feedback!
At this point I have two options for improve this patch:

Option 1: Add a simple "import" of old IPTV configuration (going from "iptv_satip_dvb?_freq" to "remap_satip_dvb?_freq"). This will provide a non-intrusive patch for current IPTV, and for the rest it will provide the option of SAT>IP exports for all MPEG-TS inputs.

Option 2: Add a new tab for MUX mappings to SAT>IP frequencies.

If you prefer the option 2, please comment about it as I need some help to start with it.

Thank you!

Jaroslav Kysela wrote:

To be honest, I'd like to see a new tab with this mapping instead this. It will allow us also to map the mux multiple times to the SAT>IP resource space.

Hi Jaroslav,

To be honest, I'm using this patch for a lot of time. And I feel you prefer a new method for mapping SAT>IP outputs to configured inputs. Furthermore, I agree that it's the best solution.

However, until you can implement this new function, I suggest to apply this patch. I’m sure other users will like to use the options provided by this patch: remap DVB-C/T inputs to DVB-S; remap complex satellite inputs to plain DVB-C inputs, etc.

The only remaining point to make this patch transparent for users, it’s the migration of the current configuration to the new format. As the SAT>IP remapped frequencies are applied to MPEG-TS inputs, instead of IPTV inputs, it’s required some migration. I analyzed the code of the “config.c” related to “config_migrate_v*()” functions. However, I feel this it’s only for convert config data over official major releases. So, please can you help me to complete this patch?

Thank you for supporting this great project!
Regards.

Hi Jaroslav,

No comment for around two weeks?
The version 4 of the patch works like a charm!

Hi Jaroslav,

I don't know enough about the source of the TVH to create a new tab with these mappings. But this patch improves a lot the use of the SAT>IP server. Futhermore, I dedicated a lot of time to resolve then problems and create a fine solution. And it's tested for weeks without problems. It works like charm!

So, please, can you tell what you think?
Thank you for your good work!

Mono Polimorph wrote:

... snip ...

I know you're itching to get your patches into tvh, and they're very welcome, but please remember patches via redmine have to be done manually and can be easily forgotten about!

Are you able to access another git service or is it just github you can't access?

Mark Clarkstone wrote:

Mono Polimorph wrote:

... snip ...

I know you're itching to get your patches into tvh, and they're very welcome, but please remember patches via redmine have to be done manually and can be easily forgotten about!

Are you able to access another git service or is it just github you can't access?

Hi Mark,

Thank you for your response. Thanks a lot!

I understand the "interference" in the development work that can occasionally this "manual"request. I don't like to be a stumble!
Futhermore, I can wait until Jaroslav (or another developer) can review the patch. However, I think it can be possible to write some "comment" here, even if it's a simple: "pending to check" or "seems right, pending".

In any case: I can't access any git service. I have a several limitations to access them. And I can't change this. The only solution I see it's sending the patch to another person. So, what do you prefer, to post here, or to send it a colleague and let him generate the PR?

Regards!

I can submit your patches on Git if you want... Tell me.

Pablo Rodríguez wrote:

I can submit your patches on Git if you want... Tell me.

Thanxs a lot, Pablo!

As the patches are published here, I put the list of pending patches here:

• http://www.tvheadend.org/issues/4784 (get version 4).
• http://www.tvheadend.org/issues/4938
• http://www.tvheadend.org/issues/4934

You only need to clone the git-hub and apply one patch for each PR.
Regards.

Mono Polimorph wrote:

Pablo Rodríguez wrote:

I can submit your patches on Git if you want... Tell me.

Thanxs a lot, Pablo!

As the patches are published here, I put the list of pending patches here:

• http://www.tvheadend.org/issues/4784 (get version 4).
• http://www.tvheadend.org/issues/4938
• http://www.tvheadend.org/issues/4934

You only need to clone the git-hub and apply one patch for each PR.
Regards.

Done!

Pablo R. wrote:

Mono Polimorph wrote:

Pablo Rodríguez wrote:

Done!

Thank you, Pablo!

Any idea why this patch isn't already merged?
I'm using it for a lot of time. Zero problems! Other friends are testing it too! However, for some platforms it's useful to use official/regular releases. So the patch needs to be accepted.

Any commet?
Please!

Hi,

A month after still waiting... no comments?

Hi,

I've also been testing this, it works great. Can we get this merged please?

Flole Systems wrote:

Hi,

I've also been testing this, it works great. Can we get this merged please?

When perexg comes back off a well deserved break I'm sure he will :).

When perexg comes back off a well deserved break I'm sure he will :).

Looks like he's back now. Good!

I hope he reconsider to accept, or at last to modify and improve, this patch.

Regards.

Hi,

No news about this patch?

I don't like to have three new rows for SAT>IP in each mux. After some more thinking, we can do this a bit differently without new tab / massive UI changes. There might be only one variable labeled for example 'SAT>IP reshare name' which will point to a configuration which will describe the SAT>IP frequencies (and positions for DVB-S). Something like this - configuration file data/conf/satip-muxes:

{
  "mux1": [
    { "sys":"dvbc", "freq": 658000000 },
    { "sys":"dvbt", "freq": 312000000 },
    { "sys":"dvbs", "pos": 1, "freq": 12610500 },
    { "sys":"dvbs", "pos": 3, "freq": 11797000 }
  ],
  "mux2": {
    { "sys":"dvbt", "freq": 372000000 }
  }
}

Jaroslav Kysela wrote:

I don't like to have three new rows for SAT>IP in each mux. After some more thinking, we can do this a bit differently without new tab / massive UI changes. There might be only one variable labeled for example 'SAT>IP reshare name' which will point to a configuration which will describe the SAT>IP frequencies (and positions for DVB-S). Something like this - configuration file data/conf/satip-muxes:

[...]

First: Thank you to comment about this issue!

Regarding your suggestion: I feel it will be a lot more powerful. I hope you can implement it soon. Please let me know if there's anything I can do to help.

Regards.

No ETA from me - I don't need this. You may give a try to implement this yourself.

Jaroslav Kysela wrote:

No ETA from me - I don't need this. You may give a try to implement this yourself.

Hi Jaroslav,

I'm sad to hear that!

I use this function a lot, and other users request it... And I feel it isn't easy to me to do it.
Please, can you do some coding to start? I don't know how to generate the configuration part (data/conf/satip-muxes).

It's JSON format. You should write the configuration file yourself. Just place it to the configuration directory like files 'config' or 'epgdb.v3'. An example for parsing is in src/descrambler/descrambler.c - descrambler_init() and descrambler_load_hints().

Jaroslav Kysela wrote:

It's JSON format. You should write the configuration file yourself. Just place it to the configuration directory like files 'config' or 'epgdb.v3'. An example for parsing is in src/descrambler/descrambler.c - descrambler_init() and descrambler_load_hints().

Thank you for the tip!
I'll try.