Commandline-Interface (Windows,Linux/Wine) für den RS

[HacMat]

Guten Morgen Klaus!

 

Die Ursache für den Fehler ist vermutlich, dass der RSR eine Sender-ID aus der Timer-Liste nicht in der Sender-Liste des RS findet. Hast Du Deine Sender-Liste nachdem Du Timer gesetzt hast verändert ? Lade mir doch bitte noch Deine Sender-Liste hoch, inklusive Sub-Channels. Abrufen lässt sich diese mit http://host:port/api/getchannelsxml.html?subchannels=1.

Danke!

[Klaus Heynen]

getchannelsxml.zipHi HacMat,

 

du bist ja spät/früh unterwegs!

Im Anhang die Liste.

 

Nee, habe die Senderliste seit ca. 3 Monaten nicht verändert.

 

Nochmals vielen Dank für deine Hilfe und das super Programm!

 

Grüße Klaus

[HacMat]

Hi Klaus,

Ich habe jetzt die Ursache des Fehlers gefunden.
Die Sender-ID dieses Timers ist nicht in Deiner Sender-Liste enthalten:

<Timer Type="1" ID="{FE880A68-4C53-4925-9F1E-9976D230E785}" Enabled="-1" Priority="50" Charset="255" Date="05.01.2016" Start="00:52:00" Dur="53" End="01:45:00" PreEPG="3" PostEPG="5" Action="0" EPGEventID="11710" PDC="165943">
<Descr>Roncalli - Der Traum vom Zirkus</Descr>
<Options AdjustPAT="-1" MonitorPDC="2" RunningStatusSplit="-1"/>
<Format>2</Format>
<Folder>Auto</Folder>
<NameScheme>%name_%station_%date_%time</NameScheme>
<Source>Webinterface</Source>
<Channel ID="2359890977740975993|WDR Duisburg"/>
<Executeable>-1</Executeable>
<Recording>0</Recording>
<ID>360</ID>
<GUID>{FE880A68-4C53-4925-9F1E-9976D230E785}</GUID>
</Timer>

Hier der Eintrag des zugehörigen Senders (aus Deiner Sender-Liste):

<channel nr="37" name="WDR Duisburg" EPGID="562954321227641" flags="24" ID="2359890977747529593">
<subchannel name="WDR Duisburg (mis)" ID="2359890977747595129"/>
</channel>

Wie Du siehst ist Deine WDR Duisburg-ID hier nicht enthalten, "ähnelt" einer aber stark:

2359890977740975993 <= falsche Sender-ID in deiner Timer-Liste
2359890977747529593 <= WDR Duisburg
2359890977747595129 <= WDR Duisburg (mis)

Die Sender-ID dieses Timers ist auch sonst nirgends in Deiner Sender-Liste zu finden, d.h. sie ist schlicht und einfach ungültig.
Ich Frag mich nur, wie Du Dir die falsche Sender-ID eingefangen hast.
Hast Du diesen Timer mit dem Requester erstellt ?
Kann mir nicht vorstellen, dass die Aufnahme funktioniert hat.
Wenn doch, habe ich irgendetwas nicht richtig verstanden.

Ich habe auch die Sender-IDs aller anderen Timer geprüft. Die sind alle gültig, also in Deiner Sender-Liste enthalten.
Wenn nicht zwischendurch ein neuer Timer mit einer falschen Sender-ID erzeugt wurde, sollte der Requester mit aktiviertem 'searchTimerDB' jetzt wieder funktionieren, da der Timer ja jetzt abgelaufen ist und somit in der Timer-Liste nicht mehr vorhanden ist.
Probier es einfach mal aus und sag mir, ob es läuft.
In der nächsten Version wird der RS Requester, wenn er die Sender-ID eines Timers nicht findet, eine Fehlermeldung ausgeben und nicht mehr unkontrolliert abstürzen.

Viele Grüße,

HacMat

Edited January 5, 2016 by HacMat

[Tjod]

Die Sender-ID ist nichts was im RS irgendwo fest gesichert ist. Die wird anhand vom Empfangsparameter der Sender berechnet. Das heißt wenn sich z.B. die Audio-PID oder Video-PID eines Senders ändert ändre sich die auch leicht.

Der RS macht zwar Selber keine permanenten Änderungen an der Senderliste. Aber sowohl DVBViewer als auch RS korrigieren kleinere Änderungen automatisch beim Aufruf des Senders. Und der DVBViewer speichert die auch.

 

Besonders entscheidend ist das für die Lokalzeiten der Sender wo dann z.B. statt einem WDR sehr viele sehr viele verscheide Versionen senden. Das könnte ohne ein Automatischen ändern der PID weder wiedergegeben noch aufgenommen werden.

 

Außerhalb der Lokalzeit haben all WDR Varianten (Bielefeld, Dortmund, Düsseldorf usw.) die gleiche Audio und Video PID. Und verbrauchen so weniger Bandbreite und können mit besserer Qualität senden. Während der Lokalzeit haben alle ihre eigene Audio und Video PID und senden mit niedrigerer Datenrate.

 

Das bedeutet aber auch das die Sender-ID sowohl durch einen Senderauchlauf (aktualisieren) als auch durch Sachen wie die Lokalzeit ändern kann.

 

Der DVBViewer und der RS sind bei Änderungen an der ID sehr tolerant. Das heißt da wird einfach geguckt was am besten passt.

 

Wenn du die ID nicht Grade änderst und sie deshalb abgleichen musst. Würde ich höchstens eine Warnung ausgeben (wenn ich das richtig überblicke könnte es zu doppelten Timern führen) und die ID einfach so lassen. Da der RS ziemlich sich bei dem Timer auch den richtigen Sender aufnimmt.

 

Der Timer mit der abweichende ID wurde eventuell über den DVBViewer während der Lokalzeit Programmiert.

[HacMat]

Danke Tjod,

 

das erklärt ja alles.

Ich werde vorerst, wie Du vorschlägst in solchen Fällen nur eine Warnung ausgeben.

Ist schließlich eher selten, dass sich die Sender-ID ändert.

 

Gruß,

 

HacMat

[Tjod]

Ich habe mir mal erlaubt das Topic zu verschieben und leicht umzubenennen (da der Titel abgeschnitten war).

Es wäre wahrscheinlich auch gut wenn du die aktuelle Version immer in den ersten Beitrag packen könntest. Der im ersten Beitrag zumindest einen Link auf den Beitrag mit der aktuellen Version setzen könntest.

[HacMat]

Danke, für das Verschieben und insbesondere das Umbenennen des Titels.
Vor allem der Begriff „Eigenentwicklung“ hatte eher abschreckenden Charakter. Ich fand es nur am Anfang wichtig zu betonen, dass niemand von den DVBViewer/RS- Entwicklern für das Projekt verantwortlich ist und so keine Fragen falsch adressiert werden.
Ich werde zukünftig neue Versionen in den ersten Beitrag packen oder zumindest verlinken.
Ich dachte immer, dass sich Beiträge nur zeitlich begrenzt editieren lassen. Ist ja auch irgendwie ein schlechter Stil, uralte Beiträge nochmals zu ändern; schließlich können nachfolgende Postings dadurch sinnlos erscheinen.

[Tjod]

Wie lange du Editieren kannst hängt von deinem Status ab.

Früher konnte jeder all seine Beiträge Editoren. Aber da gab es genau die Probleme, das alte Beiträge Editirt wurde und dadurch Diskussionen nicht mehr nachvollziehbar waren.

 

Das heißt Nutzer mit unter 100 Beiträgen können nur 30 Min. lang editieren. Bei Nutzern mit mehr Beiträgen geht man davon aus dass die wissen was sie machen und keinen Unfug Treiben.

 

Und Entwickler von Erweiterungen werden meist auch in eine Gruppe gepackt wo die Beschränkung weg fällt und die Begrenzung der Anhang deutlich erhöht wird.(Und das erstellen von Topics in "Plugins und AddOns" erlaubt, falls du also mal ein neues Adon anfängst )

 

Die Topic Titel kannst du auch selber anpassen in dem du den Ernte Beitrag im vollen Editiermodus bearbeitest.

[sonic3000]

Ich bin auf der Suche nach einem Plugin für den TVBrowser.

Alle mir bekannten Plugins (Capture-Plugin, TimerImportTool, DVBViewer-Plugin, Aufnahmesteuerung) funktionieren nicht mehr richtig.

Daher bin ich auf diesen Beitrag gestossen.

Ich möchte einfach nur aus dem TVBrowser, Sendungen an dem RS übergeben und wieder löschen können.

 

Ich würde das Tool gerne testen. Aber woher bekomme ich eine funktionierende Version?

 

Mein System: win10 64 bit, java8

 

VG

sonic3000

 

 

 

sorry. Die Testversion selbst gefunden

Edited January 17, 2016 by sonic3000

[Klaus Heynen]

Hi HacMat,

 

seit dem Umzug ins Plugins und Addons ist es so still geworden.

Hast Du schon was geplant um das Problem mit den sich verändernden Sender IDs zu lösen?

 

Grüße Klaus

[HacMat]

Hallo Klaus,

die Stille ist trügerisch. Das Problem mit den sich veränderen Sender-Ids bin ich als erstes angegangen und ist seit mindestens 2 Wochen behoben. Bei Timern, deren Sender-Ids der Requester in der Senderliste des RS nicht entdeckt, wird bei der nächsten Version nur noch dessen Titel mit dem übergebenen Titel verglichen und Zusatz-Infos aus dem EPG werden ignoriert. Das reicht in vielen Fällen schon aus um mehrfach vorhandene Timer zu finden. Da sich die Sender-Ids wirklich nur sehr selten ändern, leidet die Präzision der Erkennung von mehrfach vorhanden Timern darunter kaum. Vermutlich ist dieser Fehler bei Dir seitdem auch nicht mehr in Erscheinung getreten.
Sollte das anders sein und Du unter diesem Fehler sehr leiden, kann ich Dir auch eine Zwischen-Version hochladen. Die neue Version kommt aber noch in der ersten Februar-Hälfte. Vermeiden kannst Du den Fehler indem Du bei aktivierter Timer-Suche keine Timer für Fenster-Programme der Dritten Programme setzt. Falls Du es doch tust und der Requester dann plötzlich wieder jedes mal abstürzt, kannst Du Dir damit behelfen, dass Du den Timer für die Sendung des Fenster-Programms vorübergehend löschst.
Morgen muss ich aber erst mal eine Version des Clickfinder-Plug-Ins mit verlängerter Laufzeit hochladen. Das stellt nämlich übermorgen seinen Dienst ein. Wahrscheinlich entferne ich die Laufzeitbeschränkung hier ganz, die macht beim Clickfinder-Plug-In eigentlich keinen Sinn.

Viele Grüße,

HacMat

Edited January 30, 2016 by HacMat

[HacMat]

Neue Version: RSR Clickfinder Add-On 1.0.0.3

Hierbei handelt es sich nicht um eine neue Version des RS Requesters. Die Version 1.0.6.0 des Requesters ist noch bis zum 29 Februar lauffähig. Spätestens Mitte Februar veröffentliche ich auch eine neue Version des Requesters, die wieder mindestens 6 Monate lauffähig ist.

Änderung:

Die Laufzeitbeschränkung wurde komplett entfernt.

Ist das Clickfinder Add-on bereits installiert, reicht es aus die alte 'cfaddon.exe' durch die neue Datei-Version zu ersetzten.
Für Neu-Installationen findet man alle Informationen in der beigefügten Datei 'Installation.txt'.

 

Download: RSR Clickfinder-Add-on 1.0.0.3.zip

Edited February 1, 2016 by HacMat

[Klaus Heynen]

Hi HacMat,

 

danke für das neue clickfinder addon, es funktioniert prima.

 

Eine RS-Requester Zwischenversion ist nicht nötig, ich habe Gedult, kein Problem.

 

Best grüße

 

Klaus

[Klaus Heynen]

Hallo HacMat,

 

ich habe noch einen Verbesserungswunsch:

A: Wenn Du die Prüfung ob eine Aufnahme/Programmierung schon vorhanden ist oder nicht, der Prüfung ob genügend Resourcen/Tuner vorhanden sind vorschalten könntest wäre das schön.

Mann würde dann nicht vergebens versuchen Resourcen frei zu manchen um dann am Ende festzustellen das die Aufnahme/Programmierung eh schon vorhanden ist.

B: Meist wird bei vorhandener Aufnahme/Programmierung der Abrechen/Ignorieren Dialog angezeigt manchmal jedoch wird nur im Textfeld angezeigt das eine Aufnahme mit xx% Ahnlichkeit vorhanden ist, der Timer wird gesetzt und muss dann manuell gelöscht werden. Ich habe noch nicht verstanden wie die Abhängigkiet da ist. Vielleicht kannst Du mir das erklären oder verbessern.

Grüße Klaus

[HacMat]

Hi Klaus,

Zu A:
Du hast recht. Die Prüfung, ob genügend Tuner vorhanden sind, muss als letztes erfolgen. Ich werde Deinen Wunsch in der nächsten Version berücksichtigt haben.

Zu B:

Kann es sein, dass Du Sender-abhängig den Schlüssel 'setReturnCode' verwendest ?
Die Fehlercodes für die Ereignisse 'Aufnahme möglicherweise schon vorhanden' und 'Timer möglicherweise schon vorhanden' sind standardmäßig 0, d.h. diese Ereignisse werden nicht als Fehler betrachtet. Die Schlüssel 'searchRecDBButtonIgnore' und 'searchTimerDBButtonIgnore' sind in diesem Fall ohne Funktion, was verwirrend ist, insbesondere dann, wenn man wie Du den Clickfinder verwendet, und einem die Rückgabecodes ziemlich egal sind, da diese vom Clickfinder eh nicht ausgewertet werden. Die Auflistung der möglicherweise schon vorhandenen Aufnahmen und Timer dient hier nur als Information, und der Requester gibt einem nicht die Chance das Setzen des Timers zu unterbinden. Ich werde dieses Verhalten bei der nächsten Version ändern. So ist das einfach zu undurchsichtig.
Schreib in die Sektion [finalization] die Zuweisung 'setReturnCode = 48,1' und das Problem sollte gelöst sein. Wenn das nicht hilft, müssen wir weiter suchen.

Viele Grüße,

HacMat

[Klaus Heynen]

setReturnCode = 48,1

 

ist bereits gesetzt.

[HacMat]

Leider tritt bei mir das Problem nie auf. Wenn 'setReturnCode = 48,1' in der Sektion '[finalization]' steht, sollte sich der Requester so nicht verhalten.

Ist dieser Fehler reproduzierbar, d.h wenn Du den Timer manuell wieder gelöscht hast, und dann über den Clickfinder direkt wieder setzt, erscheint dann auch kein Abbrechen/Ignorieren Dialog ?
Probier das bitte mal aus. Am besten mehrfach direkt hintereinander.
Ich werde später nach dem Fehler nochmals intensiver suchen. Es kann aber sein, dass ich das erst nach dem nächsten Release tue. Ich möchte erst mal die anderen Baustellen schließen.
Außerdem habe ich schon zu viel am Quelltext geändert und möglicherweise ist dieses Verhalten nur ein Seiteneffekt eines Fehlers ist, den ich bereits korrigiert habe.

Warte also am besten die nächste Version ab. Wenn der Fehler dann noch auftritt, werde ich sehr kurzfristig eine neue Version nachschieben.

[Klaus Heynen]

Alles klar, werde mal ein Bischen testen ob ich eine Systematik erkennen kann, ansonsten werde ich mal warten bis es soweit ist und möglicherweise sich dieser kleine Bug schon in Wohlgefallen aufgelöst hat.

[sir drake]

Hallo HacMat,

auch ich gehöre zu denen, die dein RS Request Tool im Einsatz haben.
Vielen Dank für deinen Einsatz und ich gratuliere dir zu diesem Erfolg.

 

Ein für mich immer wieder kehrendes Problem, sind Serien.

 

Ist die Serie als solches in den EPG-Daten gekennzeichnet, funktioniert alles.

Im RS habe ich folgende NamensBildung: %year-%date_%time_%station_%name --- %title

 

Ist die Serie allerdings nicht als Serie getagged, wird --- %title nicht befüllt.

 

Diesen ( EpisodenName ) sehe ich aber oft in der Inhaltsangabe.

 

Von daher meine Frage an dich, ob es möglich ist, den EPG-Tag "Description" mit einer maximalen Anzahl von Zeichen ( per Ini )

an den Titel anhängen zu können. Traumhaft wäre natürlich noch, diesen Konstrukt nur dann zur Anwendung zu bringen,

wenn eine bestimmte Bedingung(en) erfüllt ist.

 

zb

-ein bestimmter Sender

-ein bestimmter Serien-Titel

 

[000000000:record]

useEPGTitle_and_Desc = on

 

 

viele Grüße
Drake

[HacMat]

Hallo Drake,

'%title' müsste genaugenommen '%EPG-title' heißen. '%title' steht also nicht für den Titel, den Du übergibst, sondern für den Titel, den der RS im EPG findet.

Wenn zum Zeitpunkt der Timer-Erstellung ein EPG für den Sende-Termin vorhanden ist, nutzt der RS Requester Http-Requests des Web-Interfaces, um den Timer zu erstellen. In diesem Fall wird '%title' immer gefüllt sein.

Bei den öffentlich-rechtlichen Sendern liegt das EPG für knapp 3 Wochen vor, bei den Privaten meistens nur für wenige Tage. Liegt kein EPG zum Zeitpunkt des Sendetermins vor, kann der RS Requester die Timer nur über die Web-API erstellen, da für die Timer-Generierung durch Requests des Web-Interfaces das vorhandenen sein eines EPG-Eintrages Voraussetzung ist. Der RS gleicht die über die Web-API erstellten Timer nicht mit den dann zum Sendetermin vorliegenden EPG-Daten zur Sendung ab. Er greift sich also beispielsweise nicht den EPG-Title und füllt damit '%title'; '%title' bleibt also leer.

 

Von daher meine Frage an dich, ob es möglich ist, den EPG-Tag "Description" mit einer maximalen Anzahl von Zeichen ( per Ini )

an den Titel anhängen zu können. Traumhaft wäre natürlich noch, diesen Konstrukt nur dann zur Anwendung zu bringen,

wenn eine bestimmte Bedingung(en) erfüllt ist.

 

Das ist leider nicht realisierbar. Weil die Ursache deines Problems ja letztendlich der fehlende EPG-Eintrag ist, und den benötigst Du hier auch. Zudem hat der RS Requester zum Sendetermin keinen Einfluss mehr auf die Dateinamensvergabe des RS.
Ich würde an Deiner Stelle erst mal das TV-Daten-Update deiner „Programmzeitschrift“ auf 2 Wochen begrenzen. Damit fällt das Problem für die öffentlich rechtlichen Sender schon mal weg. Solltest Du den TV-Browser verwenden, kannst Du '%name' noch beliebig mit Zusatz-Infos aus den TV-Browser Daten ergänzen, in dem Du sie sie mit '-timerName' übergibst. '%name' repräsentiert beim RS den Name des Timers, den Du frei wählen kannst. '-title' sollte der möglichst unveränderte Titel der Sendung sein, da der u. a. auch als Such-Schlüssel im EPG dient.
Wie man mit dem TV-Browser maximal aussagekräftige Serien-Dateinamen bastelt, wurde hier im Thread schon ausführlich diskutiert. Lies Dir die entsprechenden Posting am besten nochmals durch und frag einfach nochmal, wenn Dir etwas unklar ist.

Viele Grüße,

HacMat

[sir drake]

Hallo HacMat,

danke für deine Ausführungen.

ich schwenke jetzt mit meiner Idee von "Vor der Aufnahme" auf "Nach der Aufnahme" um.

 

Hole mir per "http://localhost:8089/api/recordings.html?utf8" die Recordings und entscheide dann wenn der node <info> leer ist, das ich mir x-zeichen vom node <desc> hole.

 

klappt soweit ganz gut und löst mein aktuelles Problem.

 

viele grüße

Drake

[HacMat]

@Drake

Danke für die Rückmeldung, Drake.

Wenn Deine Lösung irgendwann ausgereift ist, kannst Du ja Dein Script oder Programm hier allen zur Verfügung stellen. Vielleicht gibt es noch andere die es nutzen würden. Einigen scheint es wichtig zu sein, ein Maximum an Informationen in den Dateinamen zu packen.

Für den RS Requester ist mir gerade noch die Idee gekommen, dass er als Option bei fehlendem EPG die Möglichkeit bieten könnte, durch den Timer-Namen speziell gekennzeichnete provorische Timer zu setzen. Die provisorischen Timer werden, dann bei jeder Ausführung vom Requester geprüft, und bei vorhandenem EPG durch einen neuen, mit Hilfe des EPG-Eintrages erzeugten ersetzt.
Mit dieser Vorgehensweise ließe sich auch nachträglich die Verwendung von PDC und die Einbindung der dann vorhandenen EPG-Daten zur Dateinamensbildung anstoßen.
Leider könnte man immer noch nicht das Element '<desc>...</desc>' für die Dateinamensbildung nutzen, weil der RS das bislang nicht unterstützt. Man bräuchte dafür eine Variable '%desc' fürs Namensschema.

@alle

Da neue Requester-Version veröffentliche ich am Freitag.

[HacMat]

Neue Version: RS Requester 1.0.7.0

1 Erweiterungen

1.1 Neuer Parameter: ConfigSupport (Vorgabe: enabled)

Mit '-ConfigSupport disabled' ist es jetzt möglich die Anzeige von Informationen im Textfenster zu unterdrücken, die nur bei der Konfiguration des RS Requesters von Bedeutung sind. So fällt z.B. die Ausgabe der Befehlszeile und die Anzeige der eingelesenen Schlüssel und Sektionen weg, was das Textfenster wesentlich aufgeräumter erscheinen lässt.
Die Konfigurationshilfe ist standardmäßig aktiviert. Sie sollte erst abgeschaltet werden, wenn man den Requester optimal konfiguriert hat. Es ist empfehlenswert sie wieder zu aktivieren, bevor man Änderungen an der Konfiguration vornimmt.
'ConfigSupport' lässt sich nur als Parameter in der Befehlszeile verwenden. Die Verwendung als Schlüssel in einer Konfigurationsdatei ist nicht möglich.

1.2 Neuer Parameter/Schlüssel: searchRecDBorderOfOutput

Mit 'searchRecDBorderOfOutput' lässt sich jetzt festlegen in welcher Reihenfolge die Ausgabe der Aufnahmen erfolgt, bei denen es sich eventuell um eine bereits existierende Aufnahme von der Sendung handelt, die man neu aufnehmen möchte.
Standardmäßig wurden die Metadaten der Aufnahmen bisher nach Übereinstimmungsgrad des Titels absteigend sortiert ausgegeben. Die Vorgabe ist jetzt eine aufsteigende Sortierung.
Dadurch lässt sich jetzt schneller visuell erfassen, ob die Sendung wirklich schon aufgenommen wurde, weil dafür ein längeres Hoch-Scrollen seltener notwendig ist.

1.3 Neuer Parameter/Schlüssel: searchTimerDBorderOfOutput

'searchTimerDBorderOfOutput' funktioniert analog zu 'searchRecDBorderOfOutput', bezieht sich aber auf die Auflistungs-Reihenfolge von gefundenen redundanten Timern.

1.4 Neuer Parameter/Schlüssel: searchTimerDBIgnoreNearbyTimers

Bei Timern, deren Sendetermine in zeitlicher Nähe zu dem Sendetermin der aufzunehmenden Sendung liegen und eine Aufnahme des selben Senders anstoßen, ist es sehr unwahrscheinlich, dass es sich um einen redundanten Timer handelt, da Sender für gewöhnlich zwischen Wiederholungen mindestens einige Stunden Abstand halten. Folgen von Serien, deren Titelähnlichkeit untereinander oft sehr hoch ist, werden nicht selten direkt hintereinander ausgestrahlt. Wenn man den Mindestübereinstimmungsgrad des Titels für die Suche nach redundanten Timern nicht sehr hoch setzen will, damit auch wirklich alle redundanten Timer erfasst werden, werden viele dieser aufeinander folgenden Timern unnötiger Weise von der Suche erfasst und als Treffer gelistet.
Durch festlegen eines Intervalls um den Sendetermin des neuen Timers, innerhalb dem nicht nach redundanten Timern gesucht werden soll, lassen sich somit viele Fehltreffer vermeiden.
'searchTimerDBIgnoreNearbyTimers' hat keinen Einfluss auf die Suche nach Timern die einen anderen Sender nutzen, als den des neuen Timers. Redundante Timer für andere Sender werden also noch innerhalb des definierten Zeitintervalls entdeckt.
Als Vorgabe ist diese Funktion deaktiviert.

Clickfinder:
Es ist nicht empfehlenswert diese Funktion beim Clickfinder zu aktivieren, da dieser die aufzunehmende Sendungen nicht markiert, und deshalb eine Prüfung auf redundante Timer auch bei zeitlich dicht beieinander liegenden Timern sinnvoll ist.

1.5 Neuer Parameter/Schlüssel: leadTime

'leadTime' hat die gleiche Funktion die bisher 'preroll' hatte, bietet aber zusätzlich die Möglichkeit durch Zuweisung von 'default' den in der Konfiguration des RS voreingestellten Vorlauf verwenden zu lassen. Bisher war es so, dass die Vorgabe für 'preroll' 0 war, also kein Vorlauf programmiert wurde, wenn 'preroll' nicht verwendet wurde. Die Nicht-Verwendung von 'leadTime' führt dazu, dass die Vorgabe des RS verwendet wird.

1.6 Neuer Parameter/Schlüssel: followUpTime

wie 'leadTime', aber mit Bezug auf den Nachlauf.

2 Wegefallenen Parameter/Schlüsel

2.1 Entfernt: Parameter/Schlüssel 'preroll'

 

Die Funktion von 'preRoll' übernimmt jetzt leadTime'

2.2 Entfernt: Parameter/Schlüssel 'postRoll'

Die Funktion von 'postRoll' übernimmt jetzt followUpTime'

'LeadTime' und 'followUpTime' ersetzen jetzt 'preRoll' und 'postRoll'.
'preRoll' und 'postRoll' wurden komplett gestrichen und müssen durch 'LeadTime' und 'FollowUpTime' ersetzt werden.

3 Geänderte Parameter

3.1 Geänderter Parameter/Schlüssel: 'streamID'

Der Aufwand in den Sender-Sektionen jeweils eine Stream-ID zuzuweisen, um den Requester mitzuteilen welche Sender zusammen in einem Transport Stream gesendet werden, hat sich als überflüssig erwiesen. Der RS Requester nutzt jetzt als Vorgabe die vom RS abgerufene TSID (Transport Stream ID) aus der Senderliste (http://host:port/api/getchannelsxml.html?tuner=1). Die arbeitsaufwändige und fehlerträchtige manuelle Zuweisung von Stream-IDs ist nicht mehr notwendig. Alle Sender, die die gleiche TSID verwenden, werden im selben Transport Stream gesendet und sind mit nur einem einzigen Tuner parallel aufnehmbar. Die Möglichkeit der manuellen Zuweisung von Stream-IDs bleibt erhalten, mit der Einschränkung dass jetzt nur noch rein numerische Stream-IDs zugewiesen werden können. Bestehende Zuweisungen von numerischen Stream-IDs in den Sender-Sektionen müssen also nicht gelöscht werden. Es empfiehlt sich aber die manuelle Zuweisung nicht mehr zu nutzen.

Am einfachsten ist es dafür in der Sektion [finalization] folgenden Eintrag vorzunehmen:

[finalization]
...
streamID = use TSID
….

Dadurch werden alle anderen Zuweisungen der Stream-IDs überschrieben.
Wem eine aufgeräumte Konfigurationsdatei wichtig ist, kann auch alle Zuweisungen von Stream-IDs aus der Konfigurationsdatei entfernen.
Dazu verwendet man am besten einen Editor der reguläre Ausdrücke unterstützt, z.B. Notepad++ (Freeware), wählt 'Suchen und Ersetzen' (Tastaturkürzel: oft STRG+h) und aktiviert die Unterstützung für reguläre Ausdrücke.
Die Unterscheidung von Groß- und Kleinschreibung sollte deaktiviert sein.
Im Suchfeld trägt man *StreamID *= *[0-9]{1,} *\r\n ein (die Leerzeichen sind wichtig, auch das am Anfang, deshalb unbedingt alles was unterstrichen ist kopieren). Das Ersetzen-Feld bitte leer lassen; auch keine Leerzeichen hineinschreiben. Anschließend 'alles Ersetzen' betätigen.
Falls nicht-numerische Stream-IDs verwendet wurde, sieht der reguläre Ausdruck folgendermaßen aus: *StreamID *= *[a-z0-9]{1,} *\r\n
Diese Vorgehensweise entfernt alle StreamID-Zuweisungen, unabhängig ihrer Formatierung, ohne dass eine Leerzeile verbleibt.
Die explizite Zuweisung 'streamID = use TSID' ist nach dieser Aktion nicht mehr nötig, da dies bereits die Vorgabe ist.

3.2 Vorgabe geändert: Parameter/Schlüssel 'searchRecDB'

{0|off|...|60| |on|...|100} => Die Vorgabe ist jetzt enabled.
'enabled' impliziert eine Mindestähnlichkeit für den Titel bzw. Titel + Info von 60%, damit eine Aufnahme als vorhandene Aufnahme der neu aufzunehmenden Sendung betrachtet wird.

3.3 Vorgabe geändert: Parameter/Schlüssel 'searchTimerDB'

{0|off|...|80| |on|...|100} => Die Vorgabe ist ebenfalls 'enabled', was einer Mindestähnlichkeit von 80% entspricht.

3.4 Vorgabe geändert: Parameter/Schlüssel 'wordbreak'

Die Vorgabe ist jetzt 'enabled'.

Weitere Informationen zu den neuen und funktional modifizierten Schlüsseln und Parametern finden sich im Manual.

 

3.5 searchRecDB, searchTimerDB

 

Die Suche nach redundanten Timern und vorhandenen Aufnahmen ist jetzt standardmäßig aktiviert.

Wer die beiden Suchfunktionen nicht braucht:
Abschalten lassen sie sich durch hinzufügen folgender Zuweisungen in der Konfigurationsdatei:

[Request Record]
…
searchRecDB = disabled
searchTimerDB = disabled
…

Automatisiertes Setzen von Timern durch den TV-Browser:

Für das automatisierte Programmieren von Timern mit dem Plug-In 'Lieblingssendungen' ist es ratsam die Suche nach vorhandenen Timern und Aufnahmen abzuschalten, oder zumindest so zu konfigurieren, dass der Requester das Plug-In nicht blockiert, weil er auf eine Interaktion des Anwenders wartet. Das ist besonders dann wichtig, wenn der TV-Browser in regelmäßigen Abständen durch den Aufgabenplaner unbeaufsichtigt hochfährt, um Timer beispielsweise für Serien automatisiert zu setzen. Wenn man mit 'setReturnCode = 48,0' den Rückgabewert für die Ereignisse 'Redundanter Timer gefunden' und 'Aufnahme bereits vorhanden' auf 0 setzt, listet der Requester zwar trotzdem die gefundenen Timer und Aufnahmen, erzeugt den neuen Timer aber ohne weiter nachzufragen.

Das könnte z.B so aussehen:

[finalization]
setReturnCode = 48,0
…

Besser ist es aber, das man in der Aufnahmesteuerung 2 Geräte einrichtet: Eins für das manuelle setzten von Timern und eins welches nur das Plug-In 'Lieblingssendungen' nutzt und den Requester jeweils passend mit separaten Konfigurationsdateien einrichtet.

 

3.6 'adjust' wurde in 'adjustPATandPMT' umbenannt.

 

 

4 Verbesserungen

4.1 Automatischer Zeilenumbruch

Bei aktivierten automatischen Zeilenumbruch (wordbreak = enabled) erfolgt die Textausgabe jetzt deutlich zügiger.
Der Zeilenumbruch wird an kritischen Stellen verhindert, sodass die logische Strukturierung des Textes bewahrt bleibt.

4.2 Prüfung auf Timer-Konflikte

Die Prüfung auf Timer-Konflikte erfolgt jetzt erst nach der Suche nach redundanten Timern und bereits vorhandenen Aufnahmen. Dadurch wird verhindert, das man einen Timer-Konflikt durch das löschen von Timern auflöst, um hinterher festzustellen, dass schon ein Timer für die aufzunehmende Sendung existiert oder die Sendung bereits aufgenommen wurde.

 

5 Behobene Fehler

5.1 Behoben: Absturz bei der Suche nach redundanten Timern

Bei der Suche nach redundanten Timern (Parameter/Schlüssel checkTimerDB), stürzte der Requester ab, wenn die Sender-ID eines vorhandenen Timers nicht in der Sender-Liste des RS enthalten war.

5.2 Behoben: Rückgabe-Code nicht änderbar

Der Rückgabecode für das Ereignis 'Ein Timer für die Sendung ist möglicherweise schon vorhanden' war mit setReturnCode nicht manipulierbar, sondern immer 1.

5.3: Behoben: Falsche Funktion von 'searchRecDBcheckChannel' und 'searchRecDBcheckFolder'

Die mit der Zuweisung von 'enabled' an 'searchRecDBcheckChannel' und 'searchRecDBcheckFolder' aktivierten Filter, funktionierten entgegengesetzt ihrer zugedachten Funktion. d.h die Aufnahmen vom „richtigen“ Sender und die im gleichen Aufnahmeverzeichnis wie das Aufnahmeverzeichnis des neuen Timers, wurden gefiltert.

Beispiel:
'SearchRecDBcheckFolder = enabled' deaktivierte die Prüfung des Aufnahmeverzeichnisses,
anstatt sie einzuschalten.

5.4 Behoben: Automatischer Zeilenumbruch, fehlende horizontale Bildlaufleiste

Wenn eine Zeile mangels geeigneter Umbruchstellen länger als die Breite des Textausgabefensters ist, wird jetzt die horizontale Bildlaufleiste auch bei aktiviertem Zeilenumbruch korrekt eingeblendet.

 

Download: RS Requester 1.0.7.0.zip <= Die Exe-Datei ist nicht mehr lauffähig. Bitte durch die aktualisierte Exe-Datei erstzen.

Download aktualisierte Exe-Datei: rsreq.exe 1.0.7.7.zip

Edited February 29, 2016 by HacMat

[Klaus Heynen]

Hi HacMat,

 

hab nun folgedes Du hast Postroll und preroll abgeschaft, kann ich ja auch ändern, aber ein komplett Absturz bei "Altlasten" in der cfg ist nicht elegant:

 

Nach quitieren der Fehlermeldung stürzt der RS Rqester ab.

 

Die Fehler mit dem "adjust" kann ich nicht finden, habe ich in der Anleitung was übersehen, was hat sich geändert?

Da steht unter [request record] sowie [private] jeweils ein "adjust = on"

Ich hab's mal aus kommentiert aber was macht das?

 

Auch wenn nicht genügend Tuner zur Verfügung stehen "crasht" es jetzt bei mir.

 

Bei "evtl. Vorhandener Aufnahme" führt "Abruch" nicht weiteres passiert nichts, "Ignorieren" ditto.

RS Rqwester not reponding in der Fenster headline

 

Alles mit WinXP und ClickFinder 5.22a

 

Grüße

 

Klaus

RS Requester1.pdf

[HacMat]

Hallo Klaus,

 

abstürzen darf da nichts. Das der RS Requester manchmal etwas macht, was man nicht erwartet ist akzeptal. Das bedeutet meistens nur das ich die Doku noch verbessern muss.

'Adjust' wurde geändert. Der Parameter nennt sich jetzt 'adjustPATandPMT' . Der Bezeichner 'adjust' schien mir zu nichts sagend und Deine Frage nach der Bedeutung von 'adjust' überzeugt mich davon das es richtig war, 'adjust' umzubenennen. Ich habe wohl vergessen das zu dokumentieren.

PAT und PMT sind Tabellen die im Transport Stream gesendet werden. Sie dienen dafür gesendetete Sub-Streams und Nachrichten z.B das EPG den einzelnen Sendern zuordneten zu können. Wenn Du nur einen Sub-Stream des Transport-Streams aufnimmst bietet der RS die Möglichkeit diese Tabellen anzupassen. Also im Zweifelsfall einschalten. So hab ich das verstanden, Irrtum vorbehalten. Letztendlich ich das nur eine Funktion des RS die sich mit 'adjustPATandPMT' ein- und ausschalten lässt.

Ich Werde morgen Deine Abstürze mal provozieren. Eventuell wäre es dann Hilfreich, wenn Du Deine Konfigurationsdatei hochladen würdest.

 

Viele Grüße,

 

HacMat

[sir drake]

Hallo Klaus, hallo HacMat,

ich kann bestätigen, das die neue RS-Requester version bei mir auch immer abgestürzt ist.

nach der korrektur von pre und post und adjust muste ich noch meine ip-adresse

von localhost auf die ip4 ( ip6 habe ich nicht getestet ) setzen, die der Rechner hat

und dann lief es. ich benutzte tv-browser und devices = 0

 

viele Grüße
Drake

[Klaus Heynen]

Hi HatMac,

 

hier die cfg. ich bin nicht sicher aber ich glaube mittlerweile habe zu viel dran "rumgemurkst"

Requester.txt

[semko]

Mit der neuen Version habe ich diverse Probleme.

 

1. wolMACAddr:

Hier hat sich offenbar das Format geändert. In den früheren Versionen wurden die Werte mit "-" getrennt, jetzt wohl mit ":". Ich habe die cfg entsprechend geändert, trotzdem erhalte ich eine Fehlermeldung, dass der Wert fehlerhaft sein soll. Der Wert ist bis auf die Trenner unverändert und hat in den vorigen Versionen nicht zu einem Fehler geführt.

 

2. Meldung im Ausgabefenster siehe Bild.

Was will mir die vorletzte Zeile sagen? Der Timer wurde richtig angelegt.

 

3. Wenn ich das Ausgabefenster schließe, stürzt das Programm ab mit der Windows-Meldung: rsreq.exe funktioniert nicht mehr.

[HacMat]

@Drake,@Klaus,@Semko

Vielen Dank für Eure Fehlerberichte.
Ich habe es leider bisher nicht geschafft, den Fehler auf meinem Rechner (Windows 7) zu reproduzieren. Bei mir läuft wirklich alles absolut stabil.
Ich denke es ist aber wohl eher Zufall, dass es bei mir läuft und bei Euch nicht. Vermutlich habe ich eine Variable irgendwo nicht initialisiert und bei mir enthält diese zufälligerweise einen unkritischen Wert, so dass kein Absturz erfolgt.
Eine andere Möglichkeit ist, dass die Ursache ein sogenannter kritischer Wettlauf zwischen zwei Prozessen oder Threads ist und bei Euch aufgrund einer anderen Rechenleistung, das Timing ungünstiger ist als bei mir. Es kann sehr schwer sein einen solchen Fehler zu finden. Ich werde mich bei der Fehlersuche deshalb erst mal auf die erste mögliche Ursache konzentrieren.


@Semko

Danke, die Information, dass der Requester erst beim Schließen des Fensters abstürzt ist ein sehr wichtiger Hinweis.

„Sektion ist nicht vorhanden oder leer“ ist keine Fehlermeldung. Alle Sektionen in der Konfigurationsdatei, sowie die Konfigurationsdatei auch als ganzes, sind nur eine Option. Im Prinzip kann man auch einfach alles in die Befehlszeilen packen, wodurch allerdings die Flexibilität des Requesters vollkommen verloren geht. Diese Meldung soll eigentlich nur darüber informieren welche Sektionen Request-Typ-bedingt noch eingelesen würden. Sie ist eigentlich als Hilfestellung gedacht, scheint aber eher zu verwirren. Vielleicht sollte ich noch zusätzlich im Ausgabe-Fenster des Requesters darauf hinweisen, dass es sich nicht um einen Fehler handelt.
Das Format von 'wolMACaddr' sollte sich nicht geändert haben. Wenn das '-' zwischen den Hexadezimal-Zahlen nicht mehr akzeptiert wird, war das keine Absicht. Ich werde das untersuchen.

@alle

Sobald ich den Fehler gefunden habe, lade ich eine korrigierte Version hoch.
Eventuell brauche ich bei der Fehlersuche nochmal eure Hilfe. Ich melde mich dann.

Viele Grüße,

HacMat

[HacMat]

Neue Version: RS Requester 1.0.7.1

Ich bin mir nicht ganz sicher, ob ich die Absturzursache gefunden habe. Kann es leider nicht prüfen, da sich der Requester in der Version 1.0.7.0 bei mir nicht zum Abstürzen überreden ließ. Diese Version ist deshalb nur bis zum 29 Februar lauffähig. Ich habe diesmal nur die 'rsreq.exe' hoch geladen. Einfach die alte Exe-Datei durch die neue ersetzen.

1 Änderungen

1.1 Parameter/Schlüssel 'window': Vorgabe geändert.

Die Vorgabe wurde von 'enabled' auf 'topmost' geändert.

1.2 Beim Löschen von Timern wird jetzt der Sendername, anstatt der Sender-ID ausgegeben.

Die Sender-ID wird bei eingeschalteter Konfigurations-Hilfe (ConfigSupport = enabled (default))
zusätzlich mit ausgegeben.

2 Behobene Fehler der Version 1.0.7.0

2.1 Der Requester stürzte ab, wenn er beendet wurde.

Vermutlich behoben, bitte testen.

2.2 Das Argument von 'wolMACaddr' wurde nicht angenommen, wenn einer der 6 Teil-Werte 0 war.

Download: entfernt

 

Leider ist bei mir der Fehler jetzt gerade doch noch aufgetreten, sodass ich die neue Version wieder entfernen musste.

Jedenfalls habe ich jetzt den Ausnahmeoffset, sodass ich viel gezielter suchen kann.

Morgen startet ich einen neuen Versuch.

Edited February 29, 2016 by HacMat

[semko]

Danke für deine Mühe. Finde ich echt toll, dass du für uns sogar Nachtschichten einlegst :-)

[sir drake]

Guten Morgen HacMat,

 

ich teste gerne mit und prüfe in allen 3 versionen das localhost-verhalten:

 

1.0.6.0 localhost arbeitet korrekt

1.0.7.0 localhost führt zu absturz

1.0.7.1 localhost führt zu keinem Absturz und zu keiner Verbindung

 

 

1.0.6.0 192.168.178.21 arbeitet korrekt

1.0.7.0 192.168.178.21 arbeitet korrekt

1.0.7.1 192.168.178.21 arbeitet korrekt

 

 

im Anhang ( zip) findest du 3 Screenshots ( localhost bedingung unter 1.0.7.1 mit Fehler ) und meine cfg ( ini )

user/pw/mac-adress habe ich absichtlich durch xxx ersetzt.

sind aber ansonsten alle 3 mit realen werte besetzt.

 

viele Grüße
Drake

[sir drake]

report_1.0.7.1.zip

Guten Morgen HacMat,

 

ich teste gerne mit und prüfe in allen 3 versionen das localhost-verhalten:

 

1.0.6.0 localhost arbeitet korrekt

1.0.7.0 localhost führt zu absturz

1.0.7.1 localhost führt zu keinem Absturz und zu keiner Verbindung

 

 

1.0.6.0 192.168.178.21 arbeitet korrekt

1.0.7.0 192.168.178.21 arbeitet korrekt

1.0.7.1 192.168.178.21 arbeitet korrekt

 

 

im Anhang ( zip) findest du 3 Screenshots ( localhost bedingung unter 1.0.7.1 mit Fehler ) und meine cfg ( ini )

user/pw/mac-adress habe ich absichtlich durch xxx ersetzt.

sind aber ansonsten alle 3 mit realen werte besetzt.

 

viele Grüße
Drake

 

[HacMat]

Hallo Drake,

 

Dass localhost als Hostname nicht funktioniert, ist die Folge eines Bugs, den ich frisch in die Version 1.0.7.0 implementiert habe.

Das Problem ist nicht, dass localhost nicht aufgelöst würde, sondern, dass der RSR, wenn er ein Magic Packet gesendet hat und anschließend kein optionaler Standby-Timer gesetzt wurde, abstürzt.

Ist mir gestern Nacht auch passiert. Der RSR hat noch die RS Version im Textfenster ausgegeben und sich direkt danach verabschiedet. Eine Verbindung hatte er jedoch noch herstellen können. Sobald die Meldung "DVBViewer Recording Service.. " ausgegeben wurde, steht die Verbindung. Dieser Fehler ist der Grund, weshalb ich die Version 1.0.7.1 wieder rausnehmen wollte. Ist mir leider nicht gelungen, sodass Du von ihr noch gequält wurdest.

Wenn Du localhost als Hostnamen verwendest, solltest Du den Timeout hoch setzten. 2000 ms reichen oft nicht aus, um localhost nach 127.0.0.1 aufzulösen. Schein wohl kompliziert zu sein ;-) (Hat mit dem RSR nichts zu tun)

Der Fehler, dass der RSR in Version 1.0.7.0 bei einigen, beim Schließen des Fensters abstürzte und bei mir nicht hatte (?) eine andere Ursache. Der Absturz beim Beenden, sollte in der Version 1.0.7.1 behoben sein. Ich habe in meinem letzten Posting irrtümlich behauptet, dass dieser Fehler bei mir jetzt auch aufgetreten sei. Es handelt sich aber um einen Fehler, der eine ganz andere Ursache hat, als der Absturz beim Schließen des Requester-Fensters.

Der Fehler ist mit der Version 1.0.7.2 bereits behoben. Ich lade die neue Version heute Nacht noch hoch.

Sollte die Version 1.0.7.1 beim Schließen doch noch abstürzen, bitte ich Dich um eine kurze Rückmeldung. Am besten mit Angabe des Ausnahme-Offsets. An den kommst Du, wenn Du im Fenster der Fehlermeldung auf "Problemdetails einblenden" klickst.

 

Vielen Dank für Deine Mithilfe!

 

HacMat

 

p.s.:

Der Satz "1.0.7.1 localhost führt zu keinem Absturz und zu keiner Verbindung" sollte wahrscheinlich "1.0.7.1 localhost führt zu einem Absturz und zu keiner Verbindung" lauten. Oder irre ich mich da ?

Edited February 23, 2016 by HacMat

[HacMat]

So, ich wage es mal eine weitere Version des RS Requesters zu veröffentlichen.
Diese Version ist hoffentlich qualitativ etwas hochwertiger, als die letzten beiden:

RS Requester 1.0.7.2

1 Behobende Fehler

1.1 Der Requester hing sich seit Version 1.0.7.0 auf, wenn WOL eingeschaltet war, ein Magic Packet gesendet wurde, eine Verbindung zum RS zustande kam, und das optionale Erzeugen eines WOL-Standby-Timers deaktiviert war.

1.2 Falsche Zuordnung der Zusatz-Informationen bei der Ausgabe der Metadaten von Aufnahmen

Dieser Fehler betraf die Auflistung von Aufnahmen bei der Suche nach bereits vorhandenen Aufnahmen der neu aufzunehmenden Sendung.
Fehlte bei einem Eintrag, in der vom RS angeforderten XML-Liste mit den Aufnahmen, das optionale Element '<info>...</info>', wurde bei der Ausgabe der Metadaten des betreffenden Eintrages, die Zusatz-Information des nächsten, davor liegenden Eintrages mit <info>-Element ausgegeben.

Download: entfernt

Der Fehler in der Version 1.0.7.0, der einen Absturz verursachte, wenn das Fenster geschlossen wurde, sollte schon in der Version 1.0.7.1 behoben gewesen sein.
Sollte er wider erwarten doch noch auftreten, wäre für mich der im Fehler-Fenster einsehbare Ausnahme-Offset nützlich.

Gibt es keine Probleme mehr, werde ich die Version 1.0.7.2 als Grundlage für eine neue Version mit einer Laufzeit von wieder mindestens 6 Monaten nehmen. Ich werde sie noch rechtzeitig, bevor die Version 1.0.6.0 zum Monatswechsel ausläuft veröffentlichen.

 

Schlaft gut!

 

HacMat

Edited February 29, 2016 by HacMat

[sir drake]

Guten Morgen HacMat,
ich habe ab V 1.0.6.0 - 1.0.7.2 den gleichen Test wiederholt und dir in einer Matrix zusammengestellt. ( siehe Anhang ).
den timeout habe ich bewusst auf 2000 belassen Hat ja in 1.0.6.0 noch gut funktioniert mit 2000.

"Sollte die Version 1.0.7.1 beim Schließen doch noch abstürzen, ..."
In 1.0.7.1 stürzt bei mir in beiden fällen nichts ab !

"Der Satz "1.0.7.1 localhost führt zu keinem Absturz und zu keiner Verbindung" sollte wahrscheinlich "1.0.7.1 localhost führt zu einem Absturz und zu keiner Verbindung" lauten. Oder irre ich mich da ?"
Keine Verbindung + Kein Absturz

 

vg & Dank für deine Mühe !

Drake

test_cases_1.0.7.2.zip

Edited February 23, 2016 by sir drake

[Klaus Heynen]

Hi HatMac,

 

bei mir sieht es so aus:

Mit 1.0.7.1 und 1.0.7.2 habe ich keine Abstürze mehr wenn keine "Konflikte" vorliegen kann ich ganz normal mit "OK" oder "Beenden" quitieren; aber bei Aktionen bei denen der "Abrechen" oder "Ignorieren" kommt geht in beiden Fällen das Fenster nicht zu. Es wird nicht die gewählte Aktion ausgeführt und das Fenster lässt sich nur mit "x" (oben rechte Ecke) schließen. Es kommt nicht mehr zum Absturz aber funktinieren tut es auch nicht.

 

Grüße

 

KlausH

[HacMat]

@Klaus Heynen

Ich habe ab der Version 1.0.7.1 die Vorgabe für 'window' auf 'topmost' gesetzt, weil sich beim TV-Browser sonst manchmal das Fenster der Aufnahmesteuerung vordrängelt.
Du verwendest den Clickfinder und kannst deshalb 'window' wieder auf 'enabled' setzen.
Ich glaube zwar nicht, dass das etwas nützt, aber probieren schadet ja nichts. Einen logischen Zusammenhang sehe ich jedenfalls nicht.
Ist jetzt nur das erste, was mir einfiel. Ich bin erst am Anfang der Fehlersuche. Leider tritt bei mir mal wieder dieser Fehler nicht auf, was die Suche nach der Ursache erschwert. Sobald ich den Fehler gefunden habe, melde ich mich wieder.

@Drake

Danke für das ausführliche Test-Protokoll.
Nach Deinen Testergebnissen zu Urteilen funktioniert ja jetzt die Auflösung von localhost korrekt.
Das Heraufsetzen des Timeouts hätte nichts genützt. Der Parameter 'timeout' scheint wirkungslos zu sein. Ist ein Bug, der wohl schon seit längerer Zeit existiert. Da dieser Parameter eher unwichtig ist, ist es bisher nur niemanden aufgefallen - auch mir nicht. Sobald ich die Ursache für den Fehler bei Klaus Heynen gefunden habe, kümmere ich mich darum.

[HacMat]

Hallo Klaus,

Ich habe die Version 1.0.7.2 mal auf einem anderen Rechner in einer virtuellen Maschine unter XP SP3 getestet, und konnte den bei Dir auftretenen Fehler leider auch dort nicht reproduzieren.

Wird der Ignorieren-Button noch ausgegraut, wenn Du auf Abbrechen oder Ignorieren klickst, erfolgt noch eine Textausgabe, oder passiert rein gar nichts?
Ist diese Fehlfunktion stabil reproduzierbar oder läuft es manchmal doch so wie es soll?
Was passiert, wenn Du über die TAB-Taste einen der Buttons auswählst und mir der Eingabetaste bedienst?

Ich habe im Quellcode nochmal die Stelle untersucht, die die Verarbeitung und Reaktion, auf die bei der Interaktion mit den Buttons erzeugten Nachrichten betrifft, und musste feststellen, dass einige der Nachrichten, die im Requester nicht verarbeitet werden, nicht so wie es eigentlich sein sollte, an eine Default-Routine von Windows zur Verarbeitung dieser Nachrichten durchgereicht werden.
Ich habe dieses Verhalten jetzt korrigiert. Verspreche mir aber nicht viel davon, weil es bisher nie Probleme bereitet hatte. Trotzdem ist ist es einen Versuch wert. Ich habe Dir deshalb die korrigierte Version mal hochgeladen.

Viele Grüße,

HacMat

Download: entfernt

Edited February 29, 2016 by HacMat

[HacMat]

@Klaus Heynen

 

Hallo Kaus,

 

bei den bei Dir auftretenen Fehler handelt es sich sehr wahrscheinlich um einen sogenannten Deadlock, d.h 2 oder mehr Threads oder Prozesse blockieren sich sich gegenseitig. Ich konnte zwar Deinen Fehler bisher nicht reproduzieren, aber das hat nichts zu sagen. Auf Deinem Rechner ist das Timing zufälligerweise so ungünstig, dass es zu dieser Verklemmung kommt. Ich habe jetzt auf meinem Rechner solch einen Deadlock stabil erzeugen können: Immer, wenn ich auf das Schließen-Kreutz geklickt habe, während der Requester auf die Bedienung des Ignorieren-Buttons oder des Abbrechen-Buttons wartete, fror das Fenster des RSR ein. Nach nochmaligem Betätigen meldete Windows schließlich, dass der RSR nicht mehr reagiert und gab mir die Option das Programm abzuwürgen.

Die Ursache dieses Deadlocks habe ich beseitigt, und damit unter Umständen auch den Deadlock bei Dir gleich mit. Ich wäre die sehr dankbar, wenn Du die neue rsreq.exe mal ausprobieren könntest.

 

Viele Grüße,

 

HacMat

 

Download: entfernt

Edited February 29, 2016 by HacMat