JonahQuark02
08-05-23, 17:44
Hi,
I'm having issues when recording from IPTV on my Gigablue box with OpenVix 6.3.
The IPTV provider only allows a single stream at once and this causes me issues if I try and record 2 sequential programs. Because the timers have time before/after the scheduled program added they overlap. When the second recording starts it tries to make a second connection and then the 2 recordings 'fight' (The provider doesn't deny the second stream immediately, but one or other will fail after 10-15 seconds). The fighting between recordings carries on for a few minutes - each time one fails it tries to reconnect triggering another failure cycle - and then both recordings give up.
As a result I get lots of retried recordings - with each retry adding _001 on to the end of the stream file so I get recording, recording_001, recording_001_001, etc [1] until the recording gives up.
And if the second recording gives up retrying before the first recording finishes then it never 'wins' so the second program is missed.
Are there some settings I can change to make the recordings more co-operative?
At the moment I'm manually tweaking the recording when I create it to reset the start/end to ensure no overlap but if I forget then the second program fails. I don't want to change the additional time added to timers in main settings as it will affect non-IPTV recordings.
Ideally when starting the 2nd recording it would recognise it's already got a connection to the relevant stream and duplicate the retrieved data. This would seem to be what happens for receivers - a second recording doesn't seem to consume an additional receiver - but I get that the internal data stream architecture might be completely different for IPTV.
A compromise would be to get the second recording to keep retrying - as long as it retries after the first recording has ended it should at least get the majority of the program.
Thanks
[1] The recorded file naming could be a bug - rather than incrementing the number each retry, it adds another _001 onto the filename.
I'm having issues when recording from IPTV on my Gigablue box with OpenVix 6.3.
The IPTV provider only allows a single stream at once and this causes me issues if I try and record 2 sequential programs. Because the timers have time before/after the scheduled program added they overlap. When the second recording starts it tries to make a second connection and then the 2 recordings 'fight' (The provider doesn't deny the second stream immediately, but one or other will fail after 10-15 seconds). The fighting between recordings carries on for a few minutes - each time one fails it tries to reconnect triggering another failure cycle - and then both recordings give up.
As a result I get lots of retried recordings - with each retry adding _001 on to the end of the stream file so I get recording, recording_001, recording_001_001, etc [1] until the recording gives up.
And if the second recording gives up retrying before the first recording finishes then it never 'wins' so the second program is missed.
Are there some settings I can change to make the recordings more co-operative?
At the moment I'm manually tweaking the recording when I create it to reset the start/end to ensure no overlap but if I forget then the second program fails. I don't want to change the additional time added to timers in main settings as it will affect non-IPTV recordings.
Ideally when starting the 2nd recording it would recognise it's already got a connection to the relevant stream and duplicate the retrieved data. This would seem to be what happens for receivers - a second recording doesn't seem to consume an additional receiver - but I get that the internal data stream architecture might be completely different for IPTV.
A compromise would be to get the second recording to keep retrying - as long as it retries after the first recording has ended it should at least get the majority of the program.
Thanks
[1] The recorded file naming could be a bug - rather than incrementing the number each retry, it adds another _001 onto the filename.