RS 1.31 + Kodi weird behavior

[klosz007]

Hi,

 

I'm using Kodi 14.2 with RS 1.31. Here's what I have observed:

 

1. I scan channels in DVBViewer, channels work fine with Kodi frontend (DVBViewer plugin delivered with Kodi) and with DVBViewer

2. after some time (days) some of the channels do not work in Kodi (sound but no video) anymore but they playable under DVBViewer's native interface.

3. even though those channels are not playable via Kodi, I can schedule recording of them and recording succeeds (but read on...)

4. after recording completes, given channel is again playable in Kodi (so something got repaired for this channel after recording)

 

Another way to fix it is to scan channels again (then all problematic channels get fixed) but that's not very convenient to scan channels every few days. Unsure whsat happens to those channels so that they are unplayable in Kodi but still playable via DVBViewer and why recording of given channel fixes it...

 

However recordings from those problematic channels are a bit weird. I schedule one recording but I get two instead

First is very short (.ts file like 500 bytes) and unplayable, second is OK (contains what I expected).

The first recording (with very short .ts file) contains the following in its log:

 

00:26:03 / 00:00:00 (~ 0,00 MB) Start Recording
00:26:03 Channel update tcVideo tcPCR
00:26:03 Channel update -> recording split
00:26:03 / 00:00:00 (~ 0,00 MB) Stop

 

This happens with all scheduled recordings to those problematic channels with each planned recording (so if I scheduled 3 recordings, I get 6, 3 are short, 3 are OK) until I rescan channels via DVBViewer again. Then one schedule=one recording until this channel gets 'broken' again.

 

Personally I don't think it's a Kodi problem, it's rather RS or channel's problem (but why DVBViewer isn't affected then ?). But at the same time my Samsung recorder (or TV) has no issues at all with those channels.

 

Unsure if that has a meaning - all channels are encrypted, received via Technotrend CT2-4650 USB receiver equipped with CI reader and I'm using CI module/card delivered by my cable operator.

 

BR,

Zbyszek

Edited October 18, 2015 by klosz007

[james74]

RS configuration-Recordings has an option "Auto split on channel data changes". If you have that checked, it would explain the two files.

 

If the problem is caused by changes (e,g, new PIDs) on these channels, then RS can cope with that and update the database when it tunes. Change the PID in Channel Editor and you can see it change back when you tune from DVB Pro (change also shows in RS log). I assume this would also happen on a recording, but didn't check.

 

That update doesn't happen when tuning from Kodi. The RS log shows the wrong PID being selected on initial tuning, but a FTA channel still displays OK (I don't have any CI.) Same happens using the Android client (DVBV Controller). Maybe the PID correction is handled differently in these cases, and this causes problems only for decryption. I note that the wrong PID continues to be used on Kodi requests until RS is restarted (and the DataBase reloaded).

[majstang]

...and how do you mean this is a RS issue? It sounds more likely to be a Kodi RS plugin issue...maybe Kodi does not use the RS api correctly. For those kind of problems you have to ask the plugin developer at Kodi forum.

[james74]

Well, it looks as if RS corrects the PIDs when recording or streaming to D.Pro but not for a 3rd-party client. Is there an API command that would permit this? I doubt it, as developers might not be keen on 3rd-party access to the channel database.

 

OP could of course switch to D.Pro for these channels (maybe with some kind of launch command from his front-end. I would recommend trying to record - OP says that fixes the problem. Either press "record" to start a timer when problem occurs or schedule tune-only recordings for a regular overnight check on the channels affected.

[klosz007]

So... I shouldn't be using Polish translation of DVBViewer becuase that option is not very self-expanatory then But I disabled it (spli recording on channel data changes) and I no longer have two recordings for one schedule.

But it's very weird to me how this is handled because if such 'change' happens then I cannot view that channel in Kodi but it records properly and sometimes after recording given chanel repairs itself in Kodi. But sometimes it doesn't.

 

Given the explanation above, just trying to tune into a channel via DVBPro/RS should repair it for Kodi as well and doubled recordings phenomenon should go away after just one recording, right ? But it doesn't.

So I guess DVBPro (or RS) just temporarily fixes PID for itself on the go but the updated PID isn't stored in channel database. That would explain why, with 'split recoding...' option enabled, every recording of such updated channel is doubled (not just the first one) and attempt to record doesn't fix such channel for Kodi viewing.

The only option that I found to resolve such issue permanently is to delete channels and scan again. Then channels run fine in Kodi and one schedule=one recording even with this 'split recording' option enabled, until PID is changed again... Luckily I use Kodi as PVR, not as a TV set so disabling 'split recording' option cured most of my problems.

 

If this is so then personally I find it as a flaw in DVBPro/RS. If DVBPro/RS are able to detect such changes (and it should be) then new/updated PID should be stored permanently in channel database (why not add an option for this ?). My cable operator seems to be doing such changes quite frequently Samsung TV set is able to handle this transparently - no need to rescan channels, no doubled recordings.

Edited October 28, 2015 by klosz007