Passiven Standby-Modus auf dem CRP-2401CI+ CONAX nachrüsten

[FilmFan]

Also ich habe meine Geräte bewußt auf aktiven Standby eingestellt, nachdem ein SRP-2410M aus dem passiven Standby öfters programmierte Aufnahmen nicht mehr richtig durchführte. Seit der Umstellung habe ich damit keine Probleme mehr. Insofern würde ich die Aussage zum Netzteil eher nicht teilen.

[chris86]

Oh, das ist interessant!
Ich habe grundsätzlich den passiven Standby aktiv, und hatte bisher noch keine Probleme mit Aufnahmen.
Wie äußerte sich das bei dir?
Ging der Topf gar nicht erst an? Oder zur falschen Uhrzeit? Oder hatte dann keinen Empfang beim Aufnehmen?

[Twilight]

ich habe einen im passiven und den anderem im aktiven standby...noch keine aufnahmen wegen nicht einschalten verloren gegangen...
sind beides 2410er.

twilight

[FilmFan]

Ich habe grundsätzlich den passiven Standby aktiv, und hatte bisher noch keine Probleme mit Aufnahmen.
Wie äußerte sich das bei dir?
Ging der Topf gar nicht erst an? Oder zur falschen Uhrzeit? Oder hatte dann keinen Empfang beim Aufnehmen?

Soweit ich das in Erinnerung habe, ging der Recorder manchmal kurz an, dann aber wieder aus, so als würde der Strom für das vollständige Hochfahren nicht ausreichen. Eventuell ging er auch erst zu Beginn der Aufnahme aus. Manchmal fingen die Aufnahmen auch mit ca. 2 Minuten Verspätung an. Aber auch beim manuellen Einschalten hatte es deutlich über eine Minute gedauert, bis er reaktionsbereit war (ohne "Prüfe Festplatte").

[Twilight]

wenn du das so beschreibst hört sich das nach einem defekten netzteil an

twilight

[FilmFan]

Da wird wohl irgendwo eine Macke sein, aber mit aktivem Standby läuft er ja seit langem problemlos.

[wohliks]

wenn du das so beschreibst hört sich das nach einem defekten netzteil an

...oder man könnte mal einen Blick auf die Frontpanel-Batterie werfen bzw. diese prophylaktisch ersetzen...

[chris86]

Ich grabe diesen Thread mal wieder aus, da mir eben noch eine Einstellung aufgefallen ist, die möglicherweise (absichtlich oder unabsichtlich) "vergessen" wurde...

Und zwar fehlt beim CRP ohne Conax (in der 2015er Firmware) die Einstellung für "EPG auf Festplatte speichern". Beim CRP mit Conax (2014er Firmware) ist sie vorhanden.

Ob das an der Firmware-Version oder der SystemID liegt, muss ich noch näher testen.
Ebenso, ob es hier ebenfalls nur die Einstellung ist, die vergessen wurde, oder ob die komplette Funktion fehlt.

Wenn das ein paar Leute mit CRP mal überprüfen könnten, ob unter Einstellungen -> weitere Einstellungen der genannte Punkt auftaucht, wäre das sehr hilfreich.
Und ob der CRP non-Conax die EPG-Daten speichert oder nicht.
Eventuell erspart es mir dann die Firmware-Aufspiel-Orgie...

Sonst teste ich das die Tage mal durch...

[Homer]

In der 2011er Firmware fehlt diese Einstellung.

Viele Grüße
Homer

[chris86]

Vielen Dank, Homer, fürs Nachschauen!

Wahnsinn, mit so einer alten Firmware bist du unterwegs!? Und damit funktionieren alle TAPs noch einwandfrei?

(Bei MovieCutter zum Beispiel habe ich zwar immer darauf geachtet, non-UTF kompatibel zu bleiben, jedoch war das hauptsächlich theoretisch, ohne es zu testen... Also wenn dir da mal Fehler auffallen, sag gerne Bescheid!)

[chris86]

So, nach einer kleinen Firmware-Aufspiel-Aktion bin ich nun etwas weiter.
Erkenntnisse:
- Der CRP (ohne Conax) besitzt in 2014 und 2015er Firmwares ebenfalls die Funktion "EPG-Daten auf Festplatte speichern".
- Die Einstellung für diese Funktion fehlt auf dem Non-Conax-Modell konsequent.
- Die Funktion ist somit (leider) immer aktiv, und lässt sich nicht deaktivieren!

Das Conax-Modell besitzt die entsprechende Einstellung, und legt diese im EEPROM an Adresse 0x1B (das letzte Bit) ab.

Schaltet man dieses Bit beim Non-Conax-Modell um, so hat dies aber leider keinen Effekt.

Wenn nicht noch jemand eine Zauber-Idee hat, dann lässt sich diese Funktion wohl auf dem Non-Conax-CRP auf keine Weise deaktivieren

[FireBird]

Je nach eingebauten Features kann sich das Bit im EEPROM auch verschoben haben. Wenn man die Routine in der "guten" Firmware findet, die das Bit im EEPOM manipuliert, kann man versuchen diese in der "bösen" Firmware zu finden. Das wäre ein ziemlicher Zeitaufwand und es gibt natürlich keine Garantie.

[chris86]

Nun, das ist etwas, das _ich_ (leider) definitiv nicht kann.
Ich schätze auch nicht, dass das einen so erheblichen Aufwand wert wäre.
(Ich persönlich habe das EPG-Abspeichern lieber aus, da ich den Receiver sowieso nur alle paar Tage benutze, und der gespeicherte EPG dann eh abgelaufen ist, und da ich lieber weniger File-Handles geöffnet habe, z.B. um Schreibkonflikte zu vermeiden, und auch für das HDDSpindown-Feature - aber dann muss ich halt damit leben...)

PS: Ich habe sogar schon versucht, der /mnt/hd/SystemFiles/_EIT_AIR.DAT (in der der EPG abgespeichert wird), mit chmod die Schreibrechte zu entziehen - das juckt den Topf allerdings nicht.

[chris86]

Ich grabe diesen Thread mal wieder aus...

Und zwar ist mir aufgefallen, dass sich im EEPROM, welches ich ja dank FireBirds Hilfe per TAP auslesen und manipulieren kann (z.B. um den passiven Standby-Modus zu setzen), auch die MAC-Adresse des Receivers findet!!

Da ich am Wochenende etwas (zu viel) Zeit hatte und das Wetter schlecht war, habe ich mal ein TAP gebastelt, mit dem ich die MAC-Adresse anzeigen lassen und die einzelnen Stellen auch editieren kann.

Speichert man das Ganze, dann wird zwar im Menü unter System Informationen die "neue" MAC angezeigt - beim nächsten Neustart ist aber wieder die alte MAC aktiv.

Eigentlich schade...

Ich schätze mal, dass diese Stelle im EEPROM nur für die Anzeige zuständig ist, die richtige MAC aber noch woanders gespeichert wird.
Ist da jemandem etwas bekannt?

[wohliks]

Ich glaube, mich erinnern zu können, dass früher die MAC-Adresse im Netzwerk-Chip hardcodiert wurde (zwecks Einzigartigkeit und Manipulationssicherheit). Wird wohl heutzutage anders gemacht...

[Alter Sack]

Ist da jemandem etwas bekannt?

Die MAC-Adresse kann man über die serielle Schnittstelle auch dauerhaft ändern, da das aber beim
Booten passiert, wird man das vermutlich via TAP nicht bewerkstelligen können.

Aber Firebird traue ich diesbezüglich alles zu

[FireBird]

Ich habe nie nachverfolgt, wo der Loader die MAC-Adresse herholt, aber wenn Du sie wirklich ändern möchtest, musst Du, wie der Alte Sack schon geschrieben hat, Dich seriell ankoppeln, den Boot Loader stoppen und dort die MAC ändern.

Da zwar hin und wieder PDFs zu unserer BCM7405-CPU auftauchen, kann es sein, dass irgendwo die CPU-Register für die MAC-Adresse beschrieben sind, so dass Du sie zur Laufzeit ändern kannst. Aber mehr als ein

Code: Alles auswählen

#define BCHP_EMAC_0_REG_START                              0x00080000
#define BCHP_EMAC_0_REG_END                                0x000834f4

habe ich bisher nicht gefunden und wo die dann genau hingemappt werden, auch nicht.

[chris86]

Ach, war ja auch nur so eine Spinnerei...

Vielleicht hätte ich das Ändern vorher testen sollen, bevor ich mir Mühe mit einer Eingabe-GUI gemacht hätte...

[FireBird]

Ich hoffe, der Alte Sack ist nicht sauer, weil es so lange gedauert hat.

Die MAC im EEPROM dürfte schon die Richtige sein, man muss nur eine Firmware-Funktion aufrufen, dann ist die MAC-Adresse beim nächsten Boot anders. Die folgende Prozedur sucht die Firmware-Funktion und führt sie aus:

Code: Alles auswählen

void SetMacAddress(byte *MAC)
{
  static void(*_DevEeprom_SetMacAddr)(byte *MAC) = NULL;

  if(!_DevEeprom_SetMacAddr) _DevEeprom_SetMacAddr = (void*)TryResolve("DevEeprom_SetMacAddr");
  if(_DevEeprom_SetMacAddr) _DevEeprom_SetMacAddr(MAC);

}

Und so wird sie aufgerufen:

Code: Alles auswählen

byte MAC[6];

MAC[0] = 0x00;
MAC[1] = 0x0e;
MAC[2] = 0x9f;  //ist normalerweise 9e
MAC[3] = 0x04;
MAC[4] = 0x7b;
MAC[5] = 0x01;
SetMacAddress(MAC);

Danach ist noch ein Reboot fällig.

[Alter Sack]

Ich hoffe, der Alte Sack ist nicht sauer, weil es so lange gedauert hat.

Ach was, gut Ding braucht Weile

Die Herausforderungen bezgl. der Firmware werden ja immer weniger, aber wir wollen auf keinen Fall,
dass dein einrostet