24 replies to this topic

[BuGless]

What if we would change the default recording method to descramble but with ECM information?

In theory:
- The amount of extra wasted space is negligible.
- It only adds information which some boxes cannot do anything with, but it shouldn't hurt either (or does it?).
- It puts in extra robustness for those boxes that can make use of the extra information.

Suggested patch:

commit 61e3a4fc877f9fcad610dc6a487492bc68598cf3
Author: Stephen R. van den Berg <srb@cuci.nl>
Date:   Sat Dec 8 23:41:06 2012 +0100

	Record ECM by default.

	It should not hurt (the extra wasted space in the recorded file is negligible
	compared to the total file length), it just increases reliability for those
	boxes that are able to make use of the extra information afterward.

diff --git a/RecordTimer.py b/RecordTimer.py
index 7dfd705..046126c 100644
--- a/RecordTimer.py
+++ b/RecordTimer.py
@@ -110,7 +110,7 @@ class RecordTimerEntry(timer.TimerEntry, object):
  Notifications.AddNotification(Screens.Standby.TryQuitMainloop, 1, onSessionOpenCallback=RecordTimerEntry.stopTryQuitMainloop, default_yes = default_yes)
#################################################################

- def __init__(self, serviceref, begin, end, name, description, eit, disabled = False, justplay = False, afterEvent = AFTEREVENT.AUTO, checkOldTimers = False, dirname = None, tags = None, descramble = True, record_ecm = False):
+ def __init__(self, serviceref, begin, end, name, description, eit, disabled = False, justplay = False, afterEvent = AFTEREVENT.AUTO, checkOldTimers = False, dirname = None, tags = None, descramble = True, record_ecm = True):
  timer.TimerEntry.__init__(self, int(begin), int(end))

  if checkOldTimers == True:
@@ -471,7 +471,7 @@ def createTimer(xml):
  else:
  tags = None
  descramble = int(xml.get("descramble") or "1")
- record_ecm = int(xml.get("record_ecm") or "0")
+ record_ecm = int(xml.get("record_ecm") or "1")

  name = xml.get("name").encode("utf-8")
  #filename = xml.get("filename").encode("utf-8")
diff --git a/lib/python/Screens/TimerEntry.py b/lib/python/Screens/TimerEntry.py
index 05c3e5b..120c1f3 100644
--- a/lib/python/Screens/TimerEntry.py
+++ b/lib/python/Screens/TimerEntry.py
@@ -108,7 +108,7 @@ class TimerEntry(Screen, ConfigListScreen):
  else:
  shutdownString = _("shut down")
  self.timerentry_afterevent = ConfigSelection(choices = [("nothing", _("do nothing")), ("standby", _("go to standby")), ("deepstandby", shutdownString), ("auto", _("auto"))], default = afterevent)
- self.timerentry_recordingtype = ConfigSelection(choices = [("normal", _("normal")), ("descrambled+ecm", _("descramble and record ecm")), ("scrambled+ecm", _("don't descramble, record ecm"))], default = recordingtype)
+ self.timerentry_recordingtype = ConfigSelection(choices = [("descrambled+ecm", _("descramble and record ecm")), ("normal", _("normal")), ("scrambled+ecm", _("don't descramble, record ecm"))], default = recordingtype)
  self.timerentry_type = ConfigSelection(choices = [("once",_("once")), ("repeated", _("repeated"))], default = type)
  self.timerentry_name = ConfigText(default = self.timer.name, visible_width = 50, fixed_size = False)
  self.timerentry_description = ConfigText(default = self.timer.description, visible_width = 50, fixed_size = False)
diff --git a/lib/service/servicedvbrecord.cpp b/lib/service/servicedvbrecord.cpp
index 75355ab..fb2b075 100644
--- a/lib/service/servicedvbrecord.cpp
+++ b/lib/service/servicedvbrecord.cpp
@@ -18,7 +18,7 @@ eDVBServiceRecord::eDVBServiceRecord(const eServiceReferenceDVB &ref, bool isstr
  CONNECT(m_event_handler.m_eit_changed, eDVBServiceRecord::gotNewEvent);
  m_state = stateIdle;
  m_want_record = 0;
- m_record_ecm = false;
+ m_record_ecm = true;
  m_descramble = true;
  m_is_stream_client = isstreamclient;
  m_tuned = 0;

[pieterg]

I'd rather not.
On simulcrypt channels, the amount of data can be rather large.
Also, ecm has a very limited 'best before' date nowadays.
So I'd rather keep the setting disabled by default.

Edited by pieterg, 12 February 2013 - 18:09.

[Rob van der Does]

Also, ecm has a very limited 'best before' date nowadays.

That depends very much on the provider. For NL-CD that is certainly true.

[MiLo]

The ECM+descramble option is pointless for normal use:

- The decoder cannot "see" whether the descrambling actually works (other than just playing the stream and see if anything good appears to come out, like timestamps and similar stream information). Any attempt to descramble may result in a recording that has been descrambled with the wrong keys, resulting in something that cannot be repaired (descrambling is similar to scrambling, so the recording is now re-scrambled with an unknown key).

- If the old ECM information gets fed to the system, it may "reset" the subscription card when you play an old recording. This may set the card back in time, or worse.

You should either descramble while recording, or during playback at a later time. The decoder cannot reliably detect that the card is yielding "bad" data (as is the case when a Dutch CD card goed into punishment mode, and for many other cards as well), so it will happily wreck the data at any phase. Once it does that, the recorded ECM will not help at all, as the data has been "re-scrambled".

[BuGless]

- If the old ECM information gets fed to the system, it may "reset" the subscription card when you play

Aargh, ok, I see. I got lost in the terminology here. I mistakenly thought that the extra information being recorded actually contains the decoder keys which can be used to decode the stream. I understand now that what is being recorded is not the decoder key that comes back from the smartcard, but it is the information that is being *sent to* the smartcard (before sending), which is, indeed, rather pointless.

Which begs the question: why is there no option to store the smartcard responses?

[MiLo]

If you have the responses, you might as well feed them to the descrambler and be done with it. No need to store them, they aren't going to be more useful in a few hours than they are now. There are more than enough descramblers available at any time to descrambe anything the box might be viewing or recording.

[pieterg]

Which begs the question: why is there no option to store the smartcard responses?

because e2 does not have anything to do with the actual descrambling, it simply never gets hold of the control words, so it cannot record them.

[theparasol]

Yup, its only the ecm that can be recorded (or not). The controlword parsing is done by the ca demuxer and is transparent to enigma.

@Milo: Never hearth/read that the smartcard subscription can be reset by feeding it "expired" ecm's... If you try to descramble the stream while the keys on the card are already expired the stream just stays encoded. Most of the time your info is pretty good, did you experienced this personally with a specific card?

Edited by theparasol, 12 February 2013 - 21:50.

[littlesat]

It might only be helpfull in case a service could not be directly encrypted for some reason...

[MiLo]

@Milo: Never hearth/read that the smartcard subscription can be reset by feeding it "expired" ecm's... If you try to descramble the stream while the keys on the card are already expired the stream just stays encoded. Most of the time your info is pretty good, did you experienced this personally with a specific card?

This happened a few times on my SECA2 CD card in the Topfield 4000. If I played a recording from January in March, the card would get "reset" to January (*). After playing that recording, the card would go "black" as it could not process the March update. The solution was to play (of fast-forward) a few minutes of a February recording first, after which returning to live would update it again to March in a few minutes. If you went too far back, and did not have recordings of the EMM data for all the in-between months, you'd have to request a new activation of the card to get it back to the present.

(*) Actually, the card is always a month ahead, so playing January recordings would give you the keys for Januari+February, etc.

[malakudi]

@Milo: Maybe Topfield also recorded (and replay) EMMs? ECMs should not produce such kind of behaviour. enigma2 records ECMs or EMMs too?

[theparasol]

Tnx for the details Milo, that clearifies things a lot.
I think this is something we should test on engima boxes, I agree with Malakudi, feeding the card with (wrong/dated) ecm should not do anything with the entitlements/keys actually present on the card. I also suspect that your topfield box does feed the card with EMM's as those are responsible for making changes to the card firmware/key table.
I even think you proved it by replaying a more recent recording on this box to revive the card used for decoding.

Edited by theparasol, 13 February 2013 - 18:58.

[pieterg]

there's no rule which says ecm's cannot alter the state of the card

[theparasol]

As far smartcards are concerned nothing is sure or stated. Nowadays the providers use every trick to implement more protection.
Anyway, its something I can try myself but then I'll have to wait 2 months before the results can be evaluated

[pablonero]

Sorry, I meant to ask how you can have "no record ecm" by default also for instant recording? Sorry, I'm a newbie, if you could be as simple as possible, thank you.

[littlesat]

When you want to do this... you simply enable it...

[pablonero]

Thanks for the reply. I wanted to know how and by which menu you can enable or disable it. Thank you again.

Edited by pablonero, 9 August 2013 - 09:58.

[littlesat]

As far I know in the recordings setting menu....

[dirocca]

 diverse instellingen.jpg   65.97KB   49 downloads 

 

 

grtz Philip

[MiLo]

Sorry, I meant to ask how you can have "no record ecm" by default also for instant recording? Sorry, I'm a newbie, ...

As a "newbie", are you aware of the implications? (for example, have you read and, more importantly, understood, what was discussed here?)