Dann soll es so sein.
Aber wenn ich mir den Code so anschaue, kommte das GET gar nicht von mir - wer macht denn sowas?
http://www.vdr-portal.de/board…ulapi-plugin/#post1129188
Dann soll es so sein.
Aber wenn ich mir den Code so anschaue, kommte das GET gar nicht von mir - wer macht denn sowas?
http://www.vdr-portal.de/board…ulapi-plugin/#post1129188
Ich hab ja nicht gesagt, dass es von dir kommt, nur dass es nicht ganz dem Verhalten entsprcht, das ich für ein GET erwarten würde
https://github.com/yavdr/vdr-p…f55b28904cb2f4fd6d03d30b4
Habe es bei mir mal geändert. Beim intensiven testen von play und rewind gab es dann ab und an mal sowas:
Jul 1 13:39:32 yavdr kernel: [19861.870713] vdr[11103]: segfault at 10 ip 00007f17cd83a9de sp 00007fff585840a0 error 4 in libc-2.15.so[7f17cd7ba000+1b5000]
Da scheint es noch irgendwo anders zuklemmen.
Habe play und rewind noch bei den services ergänzt, die API.html angepasst und alles ins Git gepackt.
Den Audio-Kram für die API mache ich, wenn das hier abgesegnet wurde.
Den Fehler von oben erhalte ich, wenn ich mehrmals wild auf rewind klicke aber auch nicht immer.
Könnte es sein das, das 'cDevice::PrimaryDevice()->StopReplay();' in diesem Fall über den TaskScheduler aufgerufen werden muss?
cRecording* recording = Recordings.Get(recording_number);
if ( recording != NULL ) {
cDevice::PrimaryDevice()->StopReplay(); // must do this first to be able to rewind the currently replayed recording
cResumeFile ResumeFile(recording->FileName(), recording->IsPesRecording());
ResumeFile.Delete();
TaskScheduler::get()->SwitchableRecording(recording);
}
Moin,
kann damit jemand was anfangen?
(gdb) bt
#0 0x0000000000000021 in ?? ()
#1 0x0000000000485f07 in Action (this=<optimized out>) at device.c:1705
#2 cDevice::Action (this=0x1715310) at device.c:1667
#3 0x000000000050c46d in cThread::StartThread (Thread=0x1715310) at thread.c:262
#4 0x00007f0d35ac6e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#5 0x00007f0d344feccd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6 0x0000000000000000 in ?? ()
Moin!
Was tut denn der vdr in Zeile 1705 von device.c? Denk daran, die Patches anzuwenden, damit du auf den richtigen Source guckst.
Lars.
Moin,
habe jetzt im restfulapi mal ein paar esyslog eingebaut und es knallt wohl nach dem
source ist von (ya)vdr 2.0.2, device.c ist unverändert
device.c, Zeile 1696 bis 1711
// Distribute the packet to all attached receivers:
Lock();
for (int i = 0; i < MAXRECEIVERS; i++) {
if (receiver[i] && receiver[i]->WantsPid(Pid)) {
if (DetachReceivers) {
ChannelCamRelations.SetChecked(receiver[i]->ChannelID(), CamSlotNumber);
Detach(receiver[i]);
}
else
receiver[i]->Receive(b, TS_SIZE);
if (DescramblingOk)
ChannelCamRelations.SetDecrypt(receiver[i]->ChannelID(), CamSlotNumber);
}
}
Unlock();
}
Display More
Zeile 1705
P.S.: syslog mit vdr-dbg
Moin!
Dann müsste man mal prüfen, wie receiver, i usw. aussehen, vielleicht ist da ein kaputter Pointer dabei.
Oder restfulapi (oder irgend jemand anderer) macht was mit den Receivern, was nicht in Ordnung ist.
Schwer zu sagen.
Lars.
Ich habe jetzt noch mit diversen Sachen versucht, das Ganze einzugrenzen aber ich komme nicht dahinter
Der Fehler tritt auch nur auf, wenn ich so 5-10 mal schnell und direkt hintereinander auf rewind klicke (in tcpRemote). Also kein normaler Anwendungsfall.
Wenn ich mit einer Sekunde Abstand auf rewind klicke, kann ich das auch 100mal machen, da stürtzt nichts ab.
Irgendwie habe ich den Eindruck, der Fehler kommt vom vdr oder einem der patches, da dort (verständlicherweise) nicht berücksichtigt wurde, das einer wie blöd ein rewind auslöst.
P.S.: wenn ich ein bisschen mehr Zeit habe, setze ich mal einen VDR ohne Patches mit softhd und restfulapi auf...
Jup, ist mit Sicherheit eine race condition. Evtl. darf man rewind nicht aus jedem Thread aus aufrufen, sondern nur aus dem MainThread oder so.
Lars.
Lösung ist im Git
Dieser Teil ist in den MainThreadHook gezogen
if (scheduler->IsRewind()) {
cDevice::PrimaryDevice()->StopReplay(); // must do this first to be able to rewind the currently replayed recording
cResumeFile ResumeFile(recording->FileName(), recording->IsPesRecording());
ResumeFile.Delete();
scheduler->SetRewind(false);
}
und der TaskScheduler hat passend dazu sowas bekommen
bool _bRewind;
...
void SetRewind(bool bRewind) { _bRewind = bRewind; }
bool IsRewind() { return _bRewind; }
Gruß S.
Super!
Lars.
Moin,
für was steht eigendlich der 'version' tag in der info.xml?
Ich würde den gerne hochsetzen, soll das die Plugin Version sein also 0.1.3 oder
Die Version der info also 0.0.2?
Gruß S.
Keine Ahnung... Musst du mal schauen, wo sie herkommt.
Lars.
Das ist doch für eine stabile API, oder? Jedes Mal, wenn die API (in)kompatibel verändert wird, wird die Version des einzelnen Services hochgezählt, damit Applikationen erkennen können, ob sie ein Feature nutzen können oder nicht. Die Applikation weiß ja nicht, welche Version von restfulapi sie vor sich hat.
Gruß
hepi
P.S.: Von mir kommt heute auch noch mindestens ein Bugfix-Patch für restfulapi.
Mehr kriege ich heute nicht fertig:
fixed: due to bug the flags use_title, use_subtitle anduse_description were always forced to value false
https://github.com/yavdr/vdr-p…d8cf2e2ee3aed495bd57b395b
https://github.com/yavdr/vdr-p…11ceb93a27f85e2417b0d6f7a
Saman: Danke nochmal an Dich für Deine Mühe und Deine aufwändigen Patches für restfulapi!
Gruß
hepi
Moin,
mir ging es jetzt speziell um die zweite Zeile
Jedes Mal, wenn die API (in)kompatibel verändert wird, wird die Version des einzelnen Services hochgezählt
Da beim 'play' GET zu POST geworden ist, müsste dann ja in serverthread.cpp
Mein Vorschlag ist:
Plugin-Version = 0.1.3 (da neue Services dazu gekommen sind)
Version's tag = 0.0.2 (da neue Tags zu info.xxx gekommen sind)
Play service = 2 (da GET zu POST geworden ist)
Gruß S.
Ich blicke es auch noch nicht komplett, aber ich würde nicht mit jedem Commit irgendwelche Versionen hochzählen.
Die Versionen sollten wir nicht hochzählen, wenn wir stolz sind, dass wir ein besonders gutes Feature eingebaut haben, sondern wenn wir einer Applikation Hilfestellung geben wollen, ob ein neues Feature x enthalten oder ein Bug y behoben ist. Dafür muss man aber alle neuen Features und Bugs zusammen mit den Versionsnummern dokumentieren, sonst bringt es eh nix.
Solange wir zu faul sind, sowas zu dokumentieren, würde ich nirgendwo Versionsnummern hochzählen.
Viele Grüße
hepi
Der Version-Tag in info.cpp sitzt momentan auf 0.0.1.
se.write("<info xmlns=\"http://www.domain.org/restfulapi/2011/info-xml\">\n");
se.write(" <version>0.0.1</version>\n");
Diese Version sollte nach meinem Verständnis dann hochgezählt werden, wenn sich der Aufbau der Response vom info-Request ändert. Da wir meines Wissens nach in jüngster Zeit aber mit unseren Patches hier nichts geändert haben, gibt es bisher keinen Grund, diese Version hochzuzählen.
Die einzelnen Services und Plugins haben dann noch ihre eigenen Versionsnummern, wo man die Nummer anheben könnte, wenn man ein neues Feature einbaut oder einen Bug fixt, aber dies macht nur Sinn zusammen mit Dokumentation und auch Entwicklern, die die Dokumentation brauchen für ihre Applikationen.
Wenn nur drei Leute bisher Appllikationen bauen, die auf restfulapi aufbauen, und diese drei Leute auch diejenigen sind, die restfulapi weiterentwickeln, hat man wahrscheinlich den Zustand: Warum sollen wir dokumentieren, wir wissen ja, was wir gestern implementiert haben?
Letztendlich bleibt die Frage: Wozu ist die Versionsnummer des Gesamt-Plugins dann noch gut, wenn alle Features aus den Versionsnummern der Services ablesbar sind? Ich würde sie so beantworten: Eine Applikation, die überprüft, welche Features das aktuell installierte restfulapi bietet, interessiert sich nicht für die Versionsnummer des Gesamt-Plugins, sondern nur für die Versionsnummern der einzelnen Services.
Aber wenn aelo hier mitliest, kann er gern auch noch seinen Senf dazu geben, weil er die Sachen ja implementiert hat.
Viele Grüße
hepi
Hi,
https://github.com/MichaelE100…b/master/serverthread.cpp
Hier kann man die Versionen der einzelnen Services anpassen.
Meine ursprüngliche Idee war ursprünglich das Plugin mal so umzubauen dass auch mehrere Versionen der einzelnen Services parallel unterstützt werden damit die User des Plugins erst gar nicht Probleme mit inkompatibilität bekommen würden.
Da das Plugin aber mehr oder wneiger vollständig ist und ich auch keine Zeit mehr hatte viel daran weiter zu entwickeln hat sich da auch nichts mehr geändert. (Hatte noch mal überlegt das ganze auf rapidjson und libmicrohttpd zu portieren um auch https zu unterstützen, was aber dann auch an Zeit scheiterte... sry!)
Habe auch bemerkt dass auch sonst noch ein paar Versionskonstanten eingebaut sind, die Version vom info.xml kann man z.B. komplett ignorieren :-).
Schöne Grüße
Michael
Don’t have an account yet? Register yourself now and be a part of our community!