Timerliste neu laden

Moin Leute,

ich brauche mal etwas Hilfe von jemandem, der sich mit dem Linux-System auf der D-Box etwas grundlegender auskennt, was ich leider nicht tue:

Ich möchte gerne die Datei timerd.conf direkt verändern, um neue Timer-Einträge hinzufügen zu können. Das Problem dabei ist, dass die Box-Software mitbekommen muss, dass sich diese Datei geändert hat.

Da die Dokumentation in dieser Sache sehr spärlich ist, bzw. ich nicht den blassesten Schimmer hab, wo ich noch suchen sollte, bin ich mal dem Rat gefolgt, den Timer-Daemon einfach neu zu starten. Das bringt zumindest in meinen Versuchen nicht das gewünschte Resultat. Wenn ich

Code: Alles auswählen

killall -9 timerd
timerd

via Telnet ausführe, dann wird die Timer-Liste zwar in der Tat neu geladen, jedoch funktioniert der Timer dann nicht mehr. Soll heißen, dass ich zwar weiterhin die Liste einsehen, bearbeiten und erweitern kann, doch es wird kein einziger Eintrag mehr ausgeführt.

Was muss ich also tun, damit die Liste neu geladen wird und dass der Timer danach wieder ordnungsgemäß funktioniert? Ich könnte da ein paar gute Ideen gebrauchen. Ich nehme auch zur Not schlechte Ideen...

Gag

PS. Ich verwende zur Zeit das JtG-Team-Image vom letzten Oktober, das gesuchte Verfahren sollte aber auf allen Boxen funktionieren können.

Beitrag von **mb405** » Mittwoch 18. Januar 2006, 11:54

ich kann es zwar nicht prüfen, aber "neutrino neu laden" könnte helfen

Sorry, hatte ich vergessen dazu zu schreiben: Ich "muss" das programmgesteuert vom PC aus machen können.

Beitrag von **Tommy** » Mittwoch 18. Januar 2006, 12:46

machs doch über die webapi:

http://wiki.tuxbox-cvs.sourceforge.net/ ... _Interface

Hmmm.... Ich fürchte, darauf wird's hinaus laufen.

Da ich mehrere Timer in einem Durchgang hinzufügen und löschen wollte, hätte ich das praktischer empfunden, wenn ich das direkt in der timerd.conf hätte machen können.

So sind's dann zig HTTP-Aufrufe nacheinander.

Beitrag von **mb405** » Mittwoch 18. Januar 2006, 12:56

oder gleich übers webinterfache setzen, wenn wir schon dabei sind

Beitrag von **Tommy** » Mittwoch 18. Januar 2006, 13:06

Gag Halfrunt hat geschrieben:Hmmm.... Ich fürchte, darauf wird's hinaus laufen.

Da ich mehrere Timer in einem Durchgang hinzufügen und löschen wollte, hätte ich das praktischer empfunden, wenn ich das direkt in der timerd.conf hätte machen können.

So sind's dann zig HTTP-Aufrufe nacheinander.

wobei aber fraglich ist ob es sehr effektiv ist die timer.conf per ftp zu holen zu editieren und dann wieder zu schreiben, anschließend den timerd per telnet neuzustarten etc.
Da ist der Umgang mit der webapi wesentlich einfacher. Du stellst deine Liste zusammen und jagst in einer schleife die timer über den httpd

Was mich daran so ein bisserl stört ist halt, dass ich so die Liste abrufen, die schon vorhandenen Einträge mit meiner internen Liste vergleichen, überflüssige dann einzeln löschen und die neuen hinzufügen muss.

Das ganze natürlich hübsch asynchron, da ich ja immer auf die Antwort der Box warten muss. Wenn zwischendurch irgendwas ist, geht das Gerödel wieder los.

Klar geht das, hab auch kein tieferes Problem damit. Nur hatte ich es halt favorisiert, die komplette Liste im Programm zusammenzubauen und in einem Zug rüberzuschieben.

Beitrag von **Tommy** » Mittwoch 18. Januar 2006, 14:55

ich weis nicht was so schwer ist dies zu parsen und in ein eigenes proggi zu übernehmen?

Handler: http://dbox/control/timer

Parameter:
Rückgabe: Zeigt die Liste aller Timer

Rückgabeformat: [eventID] [eventType] [eventRepeat] [repcount] [announceTime] [alarmTime] [stopTime] [data]
------------------------------------------------
Parameter: action,[id],<alarm|ad,amo,ay,ah,ami>,<stop|sd,smo,sy,sh,smi>,announce,type,rep,repcount,channel_id,msg,rs
Rückgabe: ok / error

announce, type, rep und repcount analog zu oben.

action kann entweder new oder modify sein. Bei modify muss noch ein Parameter id angegeben werden, um festzulegen, welcher Timer modifiziert wird.

soweit ich weis macht der alte dboxtimer das auch nicht anders und der ist in VB geschrieben. Evtl. bekommst Du ja irgendwo die sourcen.

Das Parsen ist nicht der Akt...

Nur dem Affenzirkus mit den einzelnen HTTP-Requests (löschen und einfügen), um die Listen zu synchronisieren, wollte ich mir ersparen.

Beitrag von **Barf** » Mittwoch 18. Januar 2006, 16:01

Ich glaube es wäre relativ einfach timerd.cpp so zu erweitern, dass Signal USR1 (z.B:) getrappt wird, und löst ein neuladen vom timerd.conf aus. Also, für den Benutzer

Code: Alles auswählen

killall -USR1 timerd

oder sowas. Nicht viellecht die aller eleganteste Lösung, passt aber gut zu existierende Code, und verletzt keine gute Sitten.

@Barf

Was würde aber bei dieser Methode passieren, wenn gerade eine Aufnahme läuft?

Kann es dann nicht eventuell sein, daß die Aufnahme abbricht?

Bei der Timerprogrammierung über HTTP kann dabei jedenfalls nichts dergleichen passieren.

@Gag Halfrunt
Bei einem Streamingtool sollte das Programmieren der Timer auch bei einer laufenden Aufnahme möglich sein.

Greetz von DrStoned

DrStoned hat geschrieben:Was würde aber bei dieser Methode passieren, wenn gerade eine Aufnahme läuft?

Bei einem Streamingtool sollte das Programmieren der Timer auch bei einer laufenden Aufnahme möglich sein.

Das ist ein Argument.

Also es handelt sich hierbei um Sherlock, vielleicht hat er eine oder andere ja schon davon gehört. Ist ein Aufnahme-Manager, der die Programmierung vollautomatisch über den Premiere Movie Guide oder übers Internet vornimmt. Momentan arbeitet die Software nur mit "Jack the Grabber" zusammen, für die Standalone-Variante mit dem Box-Timer brauche ich halt diese Verbindung.

Wenn es ein Problem darstellen sollte, während einer Aufnahme da was zu machen, dann könnte ich die Zugriffe während der Zeit auch blocken. Das ist nicht das Problem.

Gag

Beitrag von **yjogol** » Donnerstag 19. Januar 2006, 20:06

Gag Halfrunt hat geschrieben:
DrStoned hat geschrieben:Was würde aber bei dieser Methode passieren, wenn gerade eine Aufnahme läuft?

Bei einem Streamingtool sollte das Programmieren der Timer auch bei einer laufenden Aufnahme möglich sein.
Das ist ein Argument.

Also es handelt sich hierbei um Sherlock, vielleicht hat er eine oder andere ja schon davon gehört. Ist ein Aufnahme-Manager, der die Programmierung vollautomatisch über den Premiere Movie Guide oder übers Internet vornimmt. Momentan arbeitet die Software nur mit "Jack the Grabber" zusammen, für die Standalone-Variante mit dem Box-Timer brauche ich halt diese Verbindung.

Wenn es ein Problem darstellen sollte, während einer Aufnahme da was zu machen, dann könnte ich die Zugriffe während der Zeit auch blocken. Das ist nicht das Problem.

Gag

Hi Gag Halfrunt,
die WebApi-Funktionen sind eigentlich für die Web-Formulare. Die API-Doku hat da einen Fehler, wie ich gerade sehe. Der Aufruf ist /fb/timer.dbox2/... für den oben genannten Aufruf.
Steuerungsfunktionen sind in der controlapi.cpp ...

Ich bin habe bei mir experimentell einen "addTimer" im nhttpd, der vorhandene Timer updated und auch Sendernamen und Datum/Uhrzeit uncodiert akzeptiert.

Der Aufruf kann aber auch nur einen Timer pro Aufruf setzen.
Aber er kann das löschen ersparen ... kommt bald ins CVS.

Gruß
yjogol

Also ich hab das jetzt soweit auf httpd umgestellt. Jetzt brauche ich nur noch mal einen Tipp, wie der Parameter "rec_dir" auszusehen hat.

Wenn ich da einfach nur ...&rec_dir=/mnt/filme/ angebe, bleibt der Eintrag leer. Muss der String irgendwie in irgendwelche Anführungszeichen, müssen die Slashes irgendwie escaped werden? Ich hab jetzt schon verschiedene Möglichkeiten ausprobiert...

Gag

Beitrag von **yjogol** » Sonntag 22. Januar 2006, 18:34

Gag Halfrunt hat geschrieben:Also ich hab das jetzt soweit auf httpd umgestellt. Jetzt brauche ich nur noch mal einen Tipp, wie der Parameter "rec_dir" auszusehen hat.

Wenn ich da einfach nur ...&rec_dir=/mnt/filme/ angebe, bleibt der Eintrag leer. Muss der String irgendwie in irgendwelche Anführungszeichen, müssen die Slashes irgendwie escaped werden? Ich hab jetzt schon verschiedene Möglichkeiten ausprobiert...

Gag

versuch es mal mit %2F start /

Gruß
yjogol

Schon probiert. Bringt auch keine Besserung...

Oder habe ich da irgendwas grundsätzlich nicht verstanden. Dur Url lautet:

http://dbox/control/timer?action=new&al ... nt%2Ffilme

Der Timer wird zwar eingetragen, aber das Aufnahmeverzeichnis bleibt leer.

Beitrag von **yjogol** » Sonntag 22. Januar 2006, 19:02

Gag Halfrunt hat geschrieben:Schon probiert. Bringt auch keine Besserung...

Oder habe ich da irgendwas grundsätzlich nicht verstanden. Dur Url lautet:

http://dbox/control/timer?action=new&al ... nt%2Ffilme

Der Timer wird zwar eingetragen, aber das Aufnahmeverzeichnis bleibt leer.

Bei mir gehts so.

Lösch mal /var/tuxbox/config/timerd.conf & reboot ... vielleicht hat die Box einen Schlaganfall

zuviel getestet.

Gruß
yjogol

Bei mir tut sich da nichts.

Beitrag von **yjogol** » Sonntag 22. Januar 2006, 19:25

Gag Halfrunt hat geschrieben:Bei mir tut sich da nichts.

von wann ist denn dein Image?
Geht es denn im Webinterface?

Gruß
yjogol

Ich hatte das JtG-Team Image vom 20.10.2005 drauf, jetzt hab ich mir das aktuelle vom 15.12.2005 geladen.

In der Web-Oberfläche kann ich das Aufnahmeverzeichnis gar nicht eingeben, da gibt es kein entsprechendes Eingabefeld.

Ist der Parameter rec_dir erst später da reingewandert? Sorry, ich verfolge die Entwicklung der Images nicht so regelmäßig.

Gag

Beitrag von **yjogol** » Sonntag 22. Januar 2006, 19:33

Wie testest du? URL im Browser ?
Wenn ja, dann Strg drücken und Refresh im Browser (IE)

Beitrag von **yjogol** » Sonntag 22. Januar 2006, 19:34

Gag Halfrunt hat geschrieben:Ich hatte das JtG-Team Image vom 20.10.2005 drauf, jetzt hab ich mir das aktuelle vom 15.12.2005 geladen.

In der Web-Oberfläche kann ich das Aufnahmeverzeichnis gar nicht eingeben, da gibt es kein entsprechendes Eingabefeld.

Ist der Parameter rec_dir erst später da reingewandert? Sorry, ich verfolge die Entwicklung der Images nicht so regelmäßig.

Gag

Jau hab ich erst am 21.12.05 geschrieben ...

Na super. Da kann ich mir ja 'nen Wolf suchen

Okay, also bis dahin kannte das httpd den rec_dir nocht nicht, die späteren Images, so sie den aktuellen Stand verwenden, werten das nach dem hier besprochenen Schema aus?

Dann baue ich das jetzt einfach ein und verweise darauf, dass man sich eben ein aktuelles Image laden muss, wenn man das Aufnahmeverzeichnis haben will. Hmpf.

Genau deshalb wollte ich ja die timerd.conf direkt bearbeiten.

Na, jedenfalls bin ich jetzt halbwegs froh, dass ich doch nicht bekloppt bin...

Gag

Beitrag von **yjogol** » Sonntag 22. Januar 2006, 19:42