Beiträge von thomas83

Hallo Christian,

du nutzt warscheinlich vdr-xine als Ausgabe. Leider funktioniert der LiveBuffer damit nicht richtig. Solange der LiveBuffer-Patch darauf nicht angepasst wird, kannst du ihn nicht richtig nutzen, sorry.

Thomas

Hallo,

wenn du die Zeile über Receiving() eingefügt hast, kann es Nebeneffekte geben, die du wahrscheinlich nicht so haben willst. Zum Beispiel wenn gerade zwei Timer laufen mit Priorität 50 und dann ein neuer startet, mit höherer Priorität, dann wird dieser nicht auf der freien 3.Karte aufgezeichnet, sondern es wird der Timer, welche die 2.Karte belegt unterbrochen und der neue Timer nutzt die zweite Karte. Der unterbrochene Timer wird dann auf der dritten Karte fortgesetzt. Dann hättest du unnötigerweise eine kurze Unterbrechung in deiner Aufnahme.

Daher solltest du die Zeile erst nach Receiving() einfügen. Dann sollte die 3.Karte erst benutzt werden, wenn die beiden anderen Karten mit Aufnahmen beschäftigt sind.

Hallo,

du könntest cDevice::GetDevice() patchen. Dort wird entschieden, welche Karte für die Aufnahme benutzt wird. So zum Beispiel:

--- device.c.old        2006-10-14 13:21:35.000000000 +0200
+++ device.c    2006-10-14 13:18:54.000000000 +0200
@@ -296,6 +296,7 @@
          imp <<= 1; imp |= device[i]->Receiving();                                 // avoid devices that are receiving
          imp <<= 1; imp |= device[i] == cTransferControl::ReceiverDevice();        // avoid the Transfer Mode receiver device
          imp <<= 8; imp |= min(max(device[i]->Priority() + MAXPRIORITY, 0), 0xFF); // use the device with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used)
+         imp <<= 1; imp |= device[i]->CardIndex() == 2;                            // avoid card 3
          imp <<= 8; imp |= min(max(device[i]->ProvidesCa(Channel), 0), 0xFF);      // use the device that provides the lowest number of conditional access methods
          imp <<= 1; imp |= device[i]->IsPrimaryDevice();                           // avoid the primary device
          imp <<= 1; imp |= device[i]->HasDecoder();                                // avoid full featured cards

Gruß
Thomas

Hallo,

Zitat

Original von clausmuus
Wenn z.B. in 15 Minuten eine Aufnahme ansteht, und 'Mindest Event Pause' auf 30 Minuten konfiguriert ist, dan fragt der VDR beim Ausschalten ob trotz der anstehenden Aufnahme abgeschaltet werden soll. So weit so gut. Wenn ich dies nun bestätige, so wird an das shutdownscript übergeben, dass das nächste Event in 30 Minuten ansteh (was ja falsch ist)t!?!
Das war nicht immer so. Ist das nun so gewollt (kann ich mir nicht vorstellen), oder ist das nen Fehler der sich eingeschlichen hat. Gibt es schon ne Lösung dafür?

Scheint so gewollt zu sein. Es kommt wohl von dieser Änderung:

Zitat

2006-08-06: Version 1.4.1-3

- Modified the shutdown mechanism, so that the shutdown script is never given a
time in the past (reported by Helmut Auer). If a timer is currently recording,
or a recording would start within the next 30 minutes (default for the "Min.
event timeout" setup parameter), and the user insists in shutting down now, the
reboot time given to the shutdown script will correspond to a time that is
"Min. event timeout" minutes (default is 30) in the future.

Alles anzeigen

Daher kam folgender Codeabschnitt in vdr.c hinzu:

if (timer && Delta < Setup.MinEventTimeout * 60 && ForceShutdown) {
                    Delta = Setup.MinEventTimeout * 60;
                    Next = Now + Delta;
                    timer = NULL;
                    dsyslog("reboot at %s", *TimeToString(Next));
                    }

Soweit ich das mitverfolgt habe, war der Grund für diese Änderung, dass nur noch sinnvolle Zeiten für das nächste Aufwachen übergeben werden sollten. Zum Beispiel bei einer laufenden Aufnahme, wäre die nächste Startzeit in der Vergangenheit, was offensichtlich ein sinnloser Übergabewert ist. Aber auch wenn die nächste Aufnahme in wenigen Minuten z.B in 2 Minuten startet, kann das mit nvram-wakeup nicht mehr klappen, da ja ein paar Minuten vor der Aufnahme der Rechner hochfahren soll. Also würde in einem solchen Fall der Rechner gar nicht mehr starten, was dazu führt, dass alle zukünftigen Timeraufnahmen nicht klappen würden, ohne manuell zu starten. Daher wurde es so geregelt, dass eben bei Timern, die innerhalb der Mindest Event Pause starten und man trotzdem herunterfährt, der Rechner nach der Mindest Event Pause erst wieder startet, um oben genannte Probleme zu umgehen.

Aber in dem von dir beschriebenen Fall, dass der nächste Timer in 15 Minuten startet, ist dieses Verhalten etwas unglücklich. Eine Lösung wäre 'Mindest Event Pause' auf einen kleineren Wert einzustellen. Für nvram-wakeup sind mindestens 10 Minuten notwendig, also könnte z.B 12 Minuten ein guter Wert sein.

Gruß,
Thomas

Hi,

there is a bug in the rotor plugin. The following patch should solve your problem:

--- rotor.c.old	2006-06-14 23:44:27.000000000 +0200
+++ rotor.c	2006-06-14 23:46:43.000000000 +0200
@@ -96,7 +96,8 @@
       continue;
     if ((diseqc=Diseqcs.Get(source->Code(),12000,'h')) || (diseqc=Diseqcs.Get(source->Code(),12000,'v')) || (diseqc=Diseqcs.Get(source->Code(),12000,'l')) || (diseqc=Diseqcs.Get(source->Code(),12000,'r'))) 
     {
-      char *c=strdup(diseqc->Commands());
+      char *commandstring=strdup(diseqc->Commands());
+      char *c=commandstring;      
       while (c = strchr(c, '['))
       {
         char *e = strchr(++c, ']');
@@ -131,7 +132,7 @@
           break;
         }
       }
-      free(c);
+      free(commandstring);
     }
     cRotorPos *p = RotorPositions.GetfromSource(source->Code());
     if (p==RotorPositions.First())

Zitat

Original von thorsten.gehrig
hi
gibt es demnächst einen angepassten patch für 1.4.2?

Hallo,
den für vdr-1.4.2 angepassten Patch habe ich gerade hochgeladen:
http://home.vrweb.de/bergwinkl.thomas

Gruß
Thomas

Hallo,

Zitat

Original von HFlor
Hallo Thomas,

ab dem vergangenen Wochenende bin ich auch Nutzer des LiveBuffers, vielen Dank erstmal.

Ich habe ein kleines Problem beim Umschalten der Sender mit dem svdrp-Befehl "chan +", "chan nr" funktioniert.
Bei "chan +" erscheint die OSD-Meldung "Kanal nicht verfügbar" (z.Z. als 1-Karten-System)

Hardy

Alles anzeigen

Ich habe es gerade ausprobiert, und bei mir hat es funktioniert. Hast du evtl. noch andere Patches installiert?

Thomas

Zitat

Original von linux?
tag !

Ich habe jetzt endlich auch mal den Live-Puffer getestet und muss sagen , wirklich coole sache!!!!

Hat mich wirklich umgehaun wie gut das funktioniert habe nur 2 Fragen die mich etwas nachdenklich stimmen.

1) Die umschaltzeiten stören mich nicht, aber das das Bild sich erst wieder einruckeln muss schon, ist das normal und gibt es abhilfe oder kann man daran nix machen?

2) Er zuckt in 10min schritten so das das Bild kurze zeit stehn bleibt und dann wieder normal weiter läuft. Muss ich den Puffer grösser stellen oder sonst was machen? Oder ist auch das völlig normal?

Alles anzeigen

Stell bei Frameswait einen höheren Wert ein (z.B 12 sollte ein guter Wert sein), dann sollten deine Probleme weg sein. (Tretten zumindest bei mir dann nicht mehr auf)

Gruß
Thomas

Hallo Wolfgang,

die meiste Zeit verbraucht bei dir wohl das Laden der epg.data. Du kannst ja mal testweise die epg.data verschieben und beobachten, um wie viel schneller der vdr dann startet.

Zitat

Auch das "probing" der Videodevices kostet ne Menge Zeit. Was tut er da? Kann man das abstellen? Meine Konfiguration ist ja fix.

Falls du kein CI hast und du selbst kompilierst, kannst du in dvbdevice.h mal folgende Zeile (in cDvbDevice::cDvbDevice(int n)) entfernen:

ciHandler = cCiHandler::CreateCiHandler(*cDvbName(DEV_DVB_CA, n));

Dann sollte das "probing" viel schneller gehen.

Thomas

Zitat

Original von scovery
Aber ich habe eh noch ein weiteres Problem festgestellt. Mit Livebuffer kann ich praktisch den Streamdev-Server vergessen, da vorher immer erst am VDR selbst das gleiche Programm eingestellt werden muss.

Das ist aber nicht normal. Ich habe auch 2 DVB-Karten und kann ganz normal streamen, egal ob LiveBuffer aktiv ist oder nicht.

Zitat

Original von scovery
Das und das anscheinend unlösbare DiSEqC-Problem mit meiner WinTV Nova-S machen es mir eh unmöglich, den Livebuffer zu aktivieren. Für die Nova-S Plus gab's wenigstens mal einen Patch wegen DiSEqC.

Wie schaut den deine diseqc.conf aus? Hilft es denn nichts, wenn du die diseqc-Befehle ein paar mal wiederholst?

Thomas

Zitat

Original von scovery
Jetzt macht's eher Sinn.
Budget-Karte schaltet um - FF-Karte gibt aus.
Nur: weshalb bekomme ich die Meldung für beide Karten nur wenn Livebuffer zugeschaltet ist? Weil Mit Livebuffer nicht einfach nur umgeschaltet wird sondern umgeschaltet und dann die Lifebuffer-Aufzeichnung (auf der anderen Karte) wiedergegeben wird?
Lange Rede kurzer Sinn: ist also so normal?

Immer wenn von 2.Karte empfangen und über die erste ausgegeben wird, kommen zwei Meldungen. (Beim LiveBuffer genauso wie beim Transfermode). Ist also normal. Ohne LiveBuffer wird eben (meistens) die 1.Karte benutzt, daher kommt nur eine Meldung (Karte für Empfang = Karte für Ausgabe)

Zitat

Original von scovery
Mein Problem ist nicht genau sagen zu können, wo es hakt. Das Auffällige ist ja auch, dass es die Hänger nur bei Polaritätswechsel gibt. D.h. für mich dass es offenbar ein Problem mit der DiSEqC-Umschaltung gibt. D.h. ebenso, dass bei Dir ggf. mit gleichem Quelle auch kein Problem auftauchen könnte. Muss mal sehen ob ich mir mal einen normalen mind. Twin-LNB zum ausprobieren besorge (jetzt hängt der VDR am Multiswitch) - Schüssel würde leicht erreichbar sein und ein Tausch nicht problematisch.

Möglicherweise liegt das Problem bei deiner Budget-Karte. Wenn es wirklich am diseqc liegt, sollte im Log irgendetwas mit frontend retuned nach dem Kanalwechsel zu finden sein.
Du könntest mal bei ausgeschaltetem LiveBuffer folgendes testen:
Bei zwei Kanälen mit unterschiedlicher Polarisation (die beim Umschalten mit Livebuffer Probleme machen) mal im CA-Feld eine 2 reinschreiben (damit sie nur von der 2.Karte empfangen werden können). Dann zwischen diesen beiden Kanälen umschalten und schauen, ob es hier auch ohne Livebuffer Probleme gibt.

Gruß,
Thomas

Zitat

Original von scovery

Da komme ich jetzt nicht mit. Eine Karte schaltet um - die mit der ich gerade schaue. Also wieso ist "Kanalwechsel bei Karte 2 klar" - wenn "Karte 1 ausgibt"?

Beim Umschalten wählt der vdr eine Karte aus, welche den gewünschten Kanal empfangen kann (cDevice::GetDevice()). Wenn also die 2.Karte gewählt wurde, muss diese natürlichen zu dem gewünschten Kanal schalten, um diesen empfangen zu können. (somit Meldung vom vdr, dass die Karte umgeschaltet hat.) Die 1.Karte (welche das TV-Bild ausgibt) gibt nun diesen Kanal (welcher von 2.Karte empfangen wird) wieder, schaltet also die Wiedergabe auf diesen Kanal um (daher meldet vdr auch für diese Karte, dass sie umgeschaltet wurde).

Zitat

Original von infinite

würd ich ja gerne, aber wenn ein reject auftritt, lässt sich das beim patchen von ctvdr nicht wirklich ignorieren

Ich kenne zwar ctvdr nicht, aber wieso kannst du den reject nicht einfach ignorieren. Patchen bei ctvdr wird wohl ganz normal ablaufen:
Zuerst patchen, dann kompilieren.
Du hast also jetzt gepatched, es tratt aber dieser eine reject auf. Nun ignorier doch einfach, dass es diesen reject gegeben hat und kompiliere einfach trotzdem. Das sollte funktionieren, denke ich.

Zitat

Original von infinite

geil, es wird also ne neue version geben ? juhu - livebuffer ist für mich einer der besten patches.. läuft bei mir wirklich astrein, auch mit neturmels plugin
musste zwar die frameswait zahl von auf 8 erhöhen, sonst bekam ich bild / ton aussetzer, aber nun klappt es perfekt !

wird der patch für 1.4.X funken dann ?

Ja, der nächste Patch wird für 1.4.x sein.

Zitat

Original von scovery
Mein erster Gedanke war auch, dass es an dem Lnbsharing-Patch liegt (den ich gar nicht wirklich benutze, aber gerne bereit haben will für dne Falll des Falles - aber auch ohne Lnbsharing-Patch das Gleiche). Vor allem da die Hänger beim Polaritätswechsel passieren. Möglicherweise auch irgend eine Verzögerung bemn der Aussendung des DiSEqC-Signales.
Das "doppelte umschalten" (und die Hänger) sind abe rauch ohne die Decodier-Möglichkeit verschlüsselten Sendern weg.
Es gab aber auch wie weiter oben erwähnt ab vdr-1.3.46 eine Änderung mit den Karten-Prioritäten (nochmal Zitat Klaus: "avoiding the 'actual' device when starting a recording").
Also nicht ganz klar was es wirklich ist...

Meine Frage ist aber eigentlich erst mal grundsätzlich, ob es normal ist, dass mit Livebuffer-Patch mehrere LNBs umgeschaltet werden. Das würde mir schon mal weiter helfen das Problem "einzukreisen". Hab ja selbst einiges rumbasteln müssen, um den Patch bei der auf meiner c't Distri. basierenden Installation zum Laufen zu bringen.

Wirklich tunen sollten nicht beide Karten. Aber ich glaube, der vdr meldet, wenn von der 2.Karte empfangen wird einen Kanalwechsel von Karte 2 (ist ja klar) und zusätlich von Karte 1 (da diese nun diesen Kanal ausgibt)
Wie schon oben geschrieben, könnte ich evtl. mit deinen gepatchten Sourcen + setup.conf deine Probleme reproduzieren und auf Fehlersuche gehen.

Thomas

Hallo,

Zitat

Original von scovery
Ich habe ein Problem, das sich einfach nicht lösen lässt. Bei mir gibt's beim Umschalten zwischen Kanälen unterschiedlicher Polarität relativ oft einen "Hänger" von knapp zehn Sekunden bei aktivertem Livebuffer. Im Log findet man Folgendes:

Code

vdr: [25444] switching to channel 3
vdr: [25444] LNB 1: Switching device 0 to channel 3
vdr: [25444] LNB 1: Request for channel 3 on device 0. MaxBadPriority is -2
vdr: [25444] LNB 2: Request for channel 3 on device 1. MaxBadPriority is -2
vdr: [25444] LNB 2: Switching device 1 to channel 3
vdr: [25452] frontend 1 timed out while tuning to channel 3, tp 111837
vdr: [27194] replay /dev/shm/LiveBuffer/Bayerisches FS

Es gibt einen Timeout.
Aber was mich eigentlich wundert: weshalb werden denn gleich beide LNBs umgeschaltet? Bei deaktiviertem Livebuffer ist's wie es auch sein soll nur ein LNB!
Ganz interessant wird's, wenn ein Streamdev-Client eine Karte (LNB) belegt - dann wird der Request wieder nur an ein einen LNB geschickt und es gibt keine Hänger mehr.
Da scheint mir irgend etwas falsch zu laufen.

Was da bei dir falsch läuft, kann ich im Moment nicht sagen. Du hast wohl mehrere Patches drauf (aus dem Log ist z.B. der LNB-sharing patch ersichtlich). Irgendetwas könnte sich da in die Quere kommen. Damit ich das evtl. reproduzieren könnte, wäre es hilfreich zu wissen, welche Patches du genau verwendest. Am besten wäre, wenn du mir deinen gepatches Sourcecode von vdr schicken würdest. Dann könnte ich testen, ob es bei mir damit auch Probleme gibt. Um auch mit den selben Einstellungen testen zu können, wäre es hilfreich mir auch noch deine setup.conf zu schicken.

infinite:
Den Reject von recording.c kannst du normal einfach ignorieren.

Zitat

Original von rdnzl
Mir ist da noch etwas aufgefallen. Beim Zappen durch mehrsprachige Sender (z.B. Spanier, meine Audio-Konfig ist 1.deutsch 2. englisch) funktioniert die automatische Sprachauswahl mit eingeschaltetem LB zuerst nicht. Wenn ich dann eine Aufnahme starte und abspiele, kommt der englische Ton, auch beim weiteren zappen funzt das dann richtig.

Dass mit der automatischen Sprachauswahl werde ich mir in den nächsten Tagen mal ansehen und sollte in der nächsten Version dann richtig funktionieren.

Gruß
Thomas

Zitat

Original von HolgerR

Stimmt! Die Frage ist berechtigt. Ich war aufgrund der Announcements immer der Meinung, der Patch wäre eingeschlafen!

Keine Angst, der Patch ist nicht eingeschlafen. In letzter Zeit gab es nur noch kleinere Veränderungen / Verbesserungen. Bei mir selbst läuft die aktuelle Version (0.1.7) wirklich sehr stabil und zuverlässig.

Da es aber aufwendig ist, den doch recht großen Patch mit anderen Patches zu kombinieren (großer Respekt vor Frank99, der dass mit dem BigPatch immer sehr schnell nach Veröffentlichung einer neuen Version schafft), hat sich diese Mühe wohl keiner für die letzten Versionen des Patches gemacht.

Gruß
Thomas

Hallo,

kann in dem Log nichts Ungewöhnliches finden. Dass der epgscan alle freien Karten (also in deinem Fall die 2. und die 3.) benutzt, ist normal, denke ich. Zu dem Zeitpunkt der beiden frontend timeouts hast du wohl eine Aufzeichnung angesehen. Zu diesem Zeitpunkt tratt der Fehler wohl nicht auf??

Die Symptome, die du beschreibst, dass nach ca. 1 Minute im Transfermode das Bild stehen bleibt, deutet aber schon irgendwie auf den EPG-Scan hin.
Daher würde ich an deiner Stelle mal in eitscan.c cEITScanner::Process() folgende Zeile auskommentieren:

//dsyslog("EIT scan: device %d  source  %-8s tp %5d", Device->DeviceNumber() + 1, *cSource::ToString(Channel->Source()), Channel->Transponder());

So könnte man nächstes Mal, wenn der Fehler wieder auftritt, sicher sein, ob der EPG-Scan schuld hat oder nicht.

Im Bigpatch habe ich auf die Schnelle nichts gefunden, was zu diesem Fehler führen könnte. Hast du evtl. noch andere Patches drauf?

Gruß
Thomas

Zitat

Original von carwasher
richtig, in der rotor.conf ist nur der eintrag S13.0E = S19.2E. alle anderen satelliten stehen auf 0.

habs eben nochmal versucht. von astra - ard auf hotbird - sfi. eigentlich sollte der rotor nicht loslaufen - aber er tuts

bisher hatte ich deinen patch, den du mir mal geschickt hattest, in den 0.1.3 eingebaut (hoffe, du erinnerst dich daran). damit hat es einwandfrei funktioniert.

Klar erinnere ich mich daran. Die neue Zuordungstabelle sollte diesen Patch eigentlich unnötig machen.

Zitat

Original von carwasher
kann das evtl mit der diseqc.conf zusammenhaengen? die sieht bei mir im moment folgendermassen aus:

S19.2E 11700 V 9750 W15 [E0 10 38 F0] W15 [E1 10 38 F0] W15 [E1 10 38 F0] W15 [E1 10 38 F0]
S19.2E 99999 V 10600 W15 [E0 10 38 F1] W15 [E1 10 38 F1] W15 [E1 10 38 F1] W15 [E1 10 38 F1]
S19.2E 11700 H 9750 W15 [E0 10 38 F2] W15 [E1 10 38 F2] W15 [E1 10 38 F2] W15 [E1 10 38 F2]
S19.2E 99999 H 10600 W15 [E0 10 38 F3] W15 [E1 10 38 F3] W15 [E1 10 38 F3] W15 [E1 10 38 F3]
S13.0E 11700 V 9750 W15 [E0 10 38 F4] W15 [E1 10 38 F4] W15 [E1 10 38 F4] W15 [E1 10 38 F4]
S13.0E 99999 V 10600 W15 [E0 10 38 F5] W15 [E1 10 38 F5] W15 [E1 10 38 F5] W15 [E1 10 38 F5]
S13.0E 11700 H 9750 W15 [E0 10 38 F6] W15 [E1 10 38 F6] W15 [E1 10 38 F6] W15 [E1 10 38 F6]
S13.0E 99999 H 10600 W15 [E0 10 38 F7] W15 [E1 10 38 F7] W15 [E1 10 38 F7] W15 [E1 10 38 F7]
S23.5E 11700 V 9750 W15 [E0 10 38 F0] W15 [E1 10 38 F0] W15 [E1 10 38 F0] W15 [E1 10 38 F0]
S23.5E 99999 V 10600 W15 [E0 10 38 F1] W15 [E1 10 38 F1] W15 [E1 10 38 F1] W15 [E1 10 38 F1]
S23.5E 11700 H 9750 W15 [E0 10 38 F2] W15 [E1 10 38 F2] W15 [E1 10 38 F2] W15 [E1 10 38 F2]
S23.5E 99999 H 10600 W15 [E0 10 38 F3] W15 [E1 10 38 F3] W15 [E1 10 38 F3] W15 [E1 10 38 F3]
S30.0W 11700 V 9750 W15 [E0 10 38 F0] W15 [E1 10 38 F0] W15 [E1 10 38 F0] W15 [E1 10 38 F0]
S30.0W 99999 V 10600 W15 [E0 10 38 F1] W15 [E1 10 38 F1] W15 [E1 10 38 F1] W15 [E1 10 38 F1]
S30.0W 11700 H 9750 W15 [E0 10 38 F2] W15 [E1 10 38 F2] W15 [E1 10 38 F2] W15 [E1 10 38 F2]
S30.0W 99999 H 10600 W15 [E0 10 38 F3] W15 [E1 10 38 F3] W15 [E1 10 38 F3] W15 [E1 10 38 F3]

Alles anzeigen

Deine diseqc.conf ist in Ordnung, da sollte der Fehler nicht herkommen.

Könntest du mal folgende Zeile einbauen und dann das Log von ein paar Kanalwechseln posten?

--- status.c    2006-03-22 17:19:00.000000000 +0100
+++ status.c.new        2006-04-01 23:02:20.000000000 +0200
@@ -19,6 +19,7 @@
     {
       Channel = Channels.GetByNumber(ChannelNumber);
       int channelsource = RotorPositions.GetfromSource(Channel->Source())->GetCode();
+      dsyslog("Drive to angular position %s\n",*cSource::ToString(channelsource));
       if (data.card[Device->CardIndex()] && channelsource)
         if (channelsource!=data.ActualSource)
         {

Zitat

Original von carwasher
gotox mit passenden werten fuer meinen wohnort.
desweiteren habe ich hotbird 13e den astra 19.2e zugeordnet. sowei ich das verstanden habe, sollte, wenn ich auf einen hotbird-sender schalte, der rotor sich nicht drehen. das tut er aber trotzdem, egal was ich auch versuche. hast du mir evtl einen tip?

Sollte eigentlich funktionieren. Habe es gerade mit diesen Einstellungen bei mir getestet:
Wenn ich auf einen Astra-Kanal bin und dann auf einen Kanal auf Hotbird umschalte, dreht sich der Rotor nicht (bei mir ist dann natürlich kein Signal, da bei mir gedreht werden müsste).
Natürlich dreht aber die Schüssel, wenn man vorher auf einen anderen Satelliten als Astra bzw. Hotbird war. (ist auch so gewünscht, denke ich)
Kann mir im Moment nicht vorstellen, wieso es bei dir nicht funktioniert. Also noch mal zur Sicherheit:
in deiner rotor.conf müsste jetzt folgende Zeile zu finden sein:
S13.0E = S19.2E

Beschreibe mal bitte genau, von welchen Sender (Satellit) du wohin schaltest und wohin dann der Rotor dreht.

Gruß
Thomas

Hallo,

poste doch bitte noch einige Zeilen vor dem frontend timeout (es sollten ein paar Minuten vor dem Fehler sein). Vielleicht kann man daran sehen, was da falsch läuft.

Gruß
Thomas

Hallo,

neue Version des Rotor-Plugins auf:
http://home.vrweb.de/~bergwinkl.thomas/

2006-03-27: Version 0.1.4

- now displaying additionaly the status (Signal, Carrier, Viterbi, Sync)
- fixed problems with skincurses (reported by Jeremy Hall)
- fixed segfault when editablewidth is to small (thanks to Andreas Brugger)
- Added 'GotoPosition on channelswitch'
- new config file rotor.conf, where the assignment from satellite to position is stored
- with the new config file more exotic setups are possible