EPG-Buddy ein neues EPG Tool (8 Viewers)

[Palm_Maniac]

Ist ja dein Programm UND es klappt ja, wenn man kurz Hand anlegt.

Komisch ist es aber schon, dass bei dir diese andere Eingabe mit der schtasks.exe nicht funktioniert. Immerhin wird diese Art ausdrücklich von der exe unterstützt um den CMD Teil vom Argument-Teil zu trennen, WENN Leerzeichen im Pfad enthalten sind. Habe sie gerade auch mal auf ein Windows 7 los gelassen und auch dort hat sie ohne Murren die Aufgabe richtig angelegt. Wenn sie so "zerschossen" angelegt wird, funktioniert es einfach auf keinem meiner Systeme und der EPG läuft nach 14 Tagen leer. Jetzt läuft der Buddy jeden Morgen an, so wie er soll.

Man muß nur dran denken das man es berichtigt, wenn man mal neu installieren muss. Also zu erst vom Programm anlegen lassen und dann unter Aktion den Pfad und Programmaufruf berichtigen.

 

[Lehmden]

Hi.
Mal sehen, vielleicht finde ich ja doch einen halbwegs sicheren Weg, das direkt in die Registry zu schreiben. Denn ich muss auch immer Hand anlegen, wenn auch nicht aus diesem Grund. Die Option, dass die Aufgabe so bald wie möglich ausgeführt wird, falls sie zum geplanten Zeitpunkt nicht laufen konnte (z.B. weil der Rechner ausgeschaltet war), die lässt sich per schtasks.exe nicht setzen. Das ist aber extrem sinnvoll, weswegen ich das immer manuell setze. Ich habe noch nicht intensiv gesucht, aber vielleicht finde ich ja was nicht so gefährliches, um das zu erreichen...

 

[MausWiesel]

Na guten Abend,

Der Aufruf der schtasks.exe aus dem EPG-Buddy heraus ist garantiert korrekt mit dem Pfad in "". Wäre dem nicht so, könnte das nämlich nie funktionieren. Hier gibt es nur "geht" oder "geht nicht", aber nichts dazwischen. Und bei den allermeisten geht es. Von daher liegt kein Fehler im EPG-Buddy vor. Das Problem muss also an euren Systemen liegen.

OT: immer sind die Anderen Schuld.
Ich gehöre zu den allermeisten, aber nur weil mein Pfad zum EPG kein Leerzeichen enthält (D:\ProgramData\EPG-Buddy), d.h. es gibt unter den allermeisten auch einen Prozentsatz, da funktioniert es nicht deshalb, weil im EPG alles zu 1000% richtig ist, sondern weil der Effekt per Installation schon umgangen wird.

Das bedeutet eindeutig bei dir stimmt was nicht am System. Einen Pfad in " und ' setzen zu müssen, ist prinzipiell falsch. Damit funktioniert auf einem "normalen" System nichts mehr und es kommt eine Fehlermeldung. Bei dir werden die " von der Shell nicht richtig interpretiert, genau wie ich vermutet habe... Weder mit " ' noch mit ' " oder nur mit ' funktioniert das in einer normalen Shell (aka Eingabeaufforderung), sondern ausschließlich mit "... (Edit: Hab ich natürlich gerade selbst auch ausprobiert, klappt wie erwartet nur mit " sonst gar nicht)

OT: schon wieder die anderen. Ich habe nix dagegen, wenn man seine Meinung vertritt, aber der Ton macht die Musik. So viel wie hier aus der "Hüfte geschossen" und abgestritten wird, da gehen bei mir die Alarmglocken an. Vielleicht mal etwas proaktiver die Sache betrachten und nicht gleich alles abwickeln und abstreiten. Kommt einem ja vor, als ob jmd. mit der Pistole am Kopf an die Wand gestellt wird um einen Schuldigen zu finden.

Nachfolgend mal ein kleines AuoIt-Beispiel von mir. Kann jeder gern selbst mal ausprobieren.
(meine Testumgebung: WHS2011, meinen ursprünglich leerzeichenlosen EPG-Pfad habe ich extra zum Testen auf Leerzeichen angepasst).

• Option 1 ist an die Syntax vom SetSchedule im EPG-Buddy angelehnt ... Pfad wird wie in den vorangehenden Screenshots "zerrissen".
  
• Option 2 ist eine Syntax, bei der der "Leerzeichen-behaftete" Pfad in der Aufgabenplanung nicht auseinander gerissen wird.

Local $sProg = "D:\EPG Buddy\EPG-Grap.exe"
Local $sDay = "MO, DI, MI, DO, FR, SA, SO"
Local $sTime = "23:23"

Local $sOption1 = '/Create /RU SYSTEM /SC WEEKLY /D "' & $sDay & '" /TN Test1 /TR "' & $sProg & '" /ST ' & $sTime
Local $sOption2 = "/Create /RU SYSTEM /SC WEEKLY /D """ & $sDay & """ /TN Test2 /TR ""\""" & $sProg & "\"""" /ST " & $sTime

MsgBox($MB_SYSTEMMODAL, "AutoIt Example", $sOption1)
ShellExecuteWait(@SystemDir & "/schtasks.exe", $sOption1, "", "", @SW_SHOW)
MsgBox($MB_SYSTEMMODAL, "AutoIt Example", $sOption2)
ShellExecuteWait(@SystemDir & "/schtasks.exe", $sOption2, "", "", @SW_SHOW)

Dass die Syntax von Option 2 nun dazu führt, dass der Effekt mit dem Leerlaufen nach 14Tagen gefixt wird, habt ihr (wie ich es hoffentlich richtig verstanden habe) ja schon durch händische Korrektur in der Aufgabenplanung bewiesen.

PS: Ich bezweifel nicht, dass es bei einigen System auch mit "zerschossenem" Pfad trotzdem funktioniert, aber das hilft den Leidenden nicht. Ich sehe anhand der Kommandozeilen-Screenshots, das ihr schonmal mit unterschiedlichen Win10-Builds arbeitet. Evtl. wurde ja was gefixt oder auch "zerfixt". Deshalb: Immer "open minded" bleiben!!!

PPS: Wer zum genannten Thema noch was dazulernen will, kann sich hier einlesen:
Powershell and schtask with task that has a space
https://support.microsoft.com/en-us...e-path-of-the-scheduled-task-contains-a-space

 

[Lehmden]

Du vergisst dabei, das viele Leute, mich eingeschlossen, den "zerschossenen" Pfad brauchen, damit schtasks.exe überhaupt funktioniert. Verwende ich "' kommt in der Shell nur eine Fehlermeldung und schtasks arbeitet erst gar nicht. Deswegen werde ich das garantiert nicht ändern, denn dadurch würde ich mein eigenes System zerschießen. Außerdem wird das exakt so seit Jahren verwendet (erst bei MP2-Edit, dann bei MP2.1Backup&Restore und jetzt im EPG-Buddy) und es hat bis heute immer und überall völlig problemlos funktioniert. Auf einmal ist das, was seit Jahren funktioniert, völlig falsch und all die unzähligen Systeme, auf denen das im Einsatz ist, arbeiten nur "zufällig"??? Es sind nur ganz wenige Leute, die sich bisher gemeldet haben. Und das ausschließlich in Deutschland. Deswegen sind alle anderen nur "Zufallstreffer"? Seltsamer Zufall, wirklich... Allein die vielen ATSC Nutzer, mit denen ich gerade zusamen arbeite um endlich zum allerersten Mal ein einfaches EPG für die USA zu realisieren, hätten mir im Laufe der Tests garantiert gemeldet, wenn der Scheduler nicht funktionieren würde. Und dort wird immer der Standard- Pfad "C:\Program Files (x86)" verwendet (also mit Leerzeichen drin) um eine einheitliche Test- Umgebung zu haben...

Mach doch eine eigene Version, ist schließlich Open Source. Ich werde das garantiert nicht machen, so lange das dadurch bei mir nicht mehr funktioniert. Das Thema ist für mich so lange vom Tisch, bis ich einen ganz anderen Weg finde, bei dem auch die Optionen gesetzt werden können, die schtasks.exe gar nicht unterstützt. Falls du dazu etwas beitragen kannst, würde mich das sehr freuen. Für alles weitere ist mir meine begrenzte Zeit zu kostbar.

 

[mist3xyz]

Na da hab ich was losgetreten...

@Lehmden: Man könnte, die die Task erstellung mittels Registry fertig ist, eine Info anzeigen das der Fehler auftreten kann und eventuell wo und wie das zu berichtigen ist.
Das würde nicht so versierten nutzern helfen und ist von der programmierung nicht so aufwändig.


Gesendet von meinem SM-A510F mit Tapatalk

 

[Lehmden]

Ich denke, ich habe einen Weg gefunden, wie man das Problem (hoffentlich) umgehen kann, ohne das bei einem Teil der User alles "zerschossen" wird. Ist zwar viel mehr Aufwand, dafür kann ich die Aufgabe wesentlich genauer einstellen (bedeutet viel mehr Konfigurationsmöglichkeiten im EPG-Buddy für die Aufgabenplanung) und sogar eine Option anbieten, dass das System zum EPG grabben von der Aufgabenplanung aus dem Standby geweckt wird, ohne das PowerScheduler Plugin der TV Engine nutzen zu müssen. Das wird dann neben dem EPG-Buddy auch MP2.1Backup&Restore zu gute kommen...
Wird aber eine Weile dauern, bis ich das eingebaut bekomme. Aber ich denke, mit der nächsten EPG-Buddy Version, die anständiges EPG für USA/Canada und eine Option zum Einbinden externer XML Dateien bieten wird, sollte ich das hin bekommen. Allerdings steht noch nicht fest, wann wir das ATSC Zeugs fehlerfrei am laufen haben...

 

[MausWiesel]

Guten Abend miteinander,

Du vergisst dabei, das viele Leute, mich eingeschlossen, den "zerschossenen" Pfad brauchen, damit schtasks.exe überhaupt funktioniert. Verwende ich "' kommt in der Shell nur eine Fehlermeldung und schtasks arbeitet erst gar nicht. Deswegen werde ich das garantiert nicht ändern, denn dadurch würde ich mein eigenes System zerschießen.

Ich habe nirgends geschrieben, dass Du eine Double-Single-Quote-Kombination ("') verwenden sollst. Ich habe nicht einen Single Quote (') in der Option 2 meines Codebeispiels. Es sind nur Double-Quotes enthalten. Danke für's lesen Claus!
Ändern musst Du wegen mir gar nichts. Ich habe wie gesagt (eher durch Zufall) keine Leerzeichen in meinen Pfaden. Ich möchte hier nur keine Unwahrheiten/Halb-Weisheiten stehen lassen und das Projekt voranbringen, wo ich Unterstützung leisten kann. Deswegen widerspreche ich deinen Aussagen, dass es nur mit "zerschossenem" Pfad geht, bzw. ein Eintragen eines leerzeichen-behafteten Aktiontasks mit AutoIt über die ShellExecute nicht möglich ist.
Schonmal eine Aktion mit Leerzeichen-behaftetem Task per Hand in der Aufgabenplannung eingetragen? ... da werden automatisch vom Windows genauso Double-Quotes drumherum "gemeiselt" wie im zweiten Screenshot von mir.

Außerdem wird das exakt so seit Jahren verwendet (erst bei MP2-Edit, dann bei MP2.1Backup&Restore und jetzt im EPG-Buddy) und es hat bis heute immer und überall völlig problemlos funktioniert. Auf einmal ist das, was seit Jahren funktioniert, völlig falsch und all die unzähligen Systeme, auf denen das im Einsatz ist, arbeiten nur "zufällig"??? Es sind nur ganz wenige Leute, die sich bisher gemeldet haben. Und das ausschließlich in Deutschland. Deswegen sind alle anderen nur "Zufallstreffer"? Seltsamer Zufall, wirklich... Allein die vielen ATSC Nutzer, mit denen ich gerade zusamen arbeite um endlich zum allerersten Mal ein einfaches EPG für die USA zu realisieren, hätten mir im Laufe der Tests garantiert gemeldet, wenn der Scheduler nicht funktionieren würde. Und dort wird immer der Standard- Pfad "C:\Program Files (x86)" verwendet (also mit Leerzeichen drin) um eine einheitliche Test- Umgebung zu haben.

"Ging schon immer so" ist für mich als Programmierer kein Argument. Wenn ich sehe, dass es Nutzer gibt, bei denen es nicht funktioniert, dann kann ich mich nicht hinstellen und sagen "Ich bin die Sonne .. .kreiset um mich", "Ihr macht alles falsch". Man sollte offen für Verbesserungen bleiben und wenn es eine einfach smarte Lösung gibt, die den Exoten mit einem pinken Desktop-Hintergrund, einer Spracheinstellung auf koreanisch oder einem Dezimaltrennzeichen als Punkt hilft und der Masse nicht weh tut, auch nutzen.

Mach doch eine eigene Version, ist schließlich Open Source. Ich werde das garantiert nicht machen, so lange das dadurch bei mir nicht mehr funktioniert. Das Thema ist für mich so lange vom Tisch, bis ich einen ganz anderen Weg finde, bei dem auch die Optionen gesetzt werden können, die schtasks.exe gar nicht unterstützt. Falls du dazu etwas beitragen kannst, würde mich das sehr freuen. Für alles weitere ist mir meine begrenzte Zeit zu kostbar.

Eine eigene zweite Version ... das ist keine Option. Da gibt es Erstens nur zweite Sieger und Zweitens ist es viel sinnvoller bei uns wenigen "HTPC-Enthusiasten" die Energie/Freizeit in einem Projekt einzubringen. Da haben die User mehr davon. Hast Du meine "Option2" mal probiert oder woher weißt Du dass es bei Dir damit nicht mehr funktioniert?
Ansonsten ... mit Beratungresistenz kann ich ganz gut umgehen ... es müssen nicht alle "über den Tellerrand schauen" wollen. Das darf jeder für sich selbst entscheiden.

Viel Spaß noch.

 

[Lehmden]

Danke für's lesen Claus!

Das kann ich ungebraucht zurück geben. Wenn du gelesen (und verstanden, ganz wichtig) hättest, was das Problem ist, hättest du dir den ganzen Psalm sparen können.
Noch mal extra für dich zum mitlesen:

Manche Leute scheinen doppelte Anführungszeichen zu benötigen, damit das läuft. Bei anderen (wie bei mir) arbeitet schtasks.exe erst gar nicht, wenn doppelte Anführungszeichen verwendet werden. Dabei ist es (beiden Seiten) völlig Wurscht, ob es sich um ' und " oder um zweimal " handelt. Das Problem liegt überhaupt nicht auf der AutoIt Seite, sondern in der Shell... Hier wird der exakt gleiche Befehl völlig unterschiedlich verarbeitet.

Der Befehl, der bei Palm_Maniac zu einem funktionierenden Eintrag führt, bewirkt bei mir nur einen Absturz der schtasks.exe. Anders rum führt der Befehl, der bei mir einen funktionierenden Eintrag bewirkt dazu, das bei Palm_Maniac zwar ein Eintrag erzeugt wird, der aber nicht funktioniert. Wie bitteschön soll man das durch ein paar geänderte Programmzeilen unter einen Hut kriegen? Das schließt sich komplett gegenseitig aus...

Um das so direkt zu umgehen, müsste es zwei verschiedene Versionen geben, eine die einfache Anführungszeichen und eine andere, die doppelte Anführungszeichen erzeugt, je nach dem, was benötigt wird. Und genau dass wird es von meiner Seite aus nicht geben.

Deswegen werde ich in Zukunft diese Funktion gar nicht mehr verwenden. Auch, aber nicht nur wegen diesem Problem. Vor allem fehlen mir einfach wichtige Einstellungsmöglichkeiten, die man per schtasks.exe nicht erzeugen kann... Zum Beispiel die Option, dass die Aufgabe bei verpasstem Start (weil z.b. der Rechner gerade nicht eingeschaltet war) so bald wie möglich nachgeholt wird. Oder eben auch die Option, den Rechner aufwachen zu lassen, um die Aufgabe auszuführen...

In Zukunft werde ich eine fertige Aufgabe als XML Datei erzeugen und dann importieren lassen. Damit hat man all die vielen Möglichkeiten, die schtasks.exe nicht bietet und benötigt obendrein überhaupt keine Anführungszeichen, weder einfache noch doppelte...

Und damit ist dieses leidige Thema hoffentlich endgültig vom Tisch. Wir können weiter darüber reden, wenn die neue Version vorliegt. Aber ich befürchte, dass dann einige Leute statt XML unbedingt JSON Dateien haben müssen, damit es funktioniert...

 

[MausWiesel]

Servus,

Das kann ich ungebraucht zurück geben. Wenn du gelesen (und verstanden, ganz wichtig) hättest, was das Problem ist, hättest du dir den ganzen Psalm sparen können.
Noch mal extra für dich zum mitlesen:

OT: keine Garantie, keine Rücknahme und kein Umtausch, da Privatverkauf

Ganz ehrlich ... ich bin mir echt nicht sicher, ob Du meine Option2 bzw. die Syntax mal probiert hast, sonst hätte ich das nicht geschrieben. Ich kann mich täuschen und lasse mich auch gern mit den richtigen Argumenten überzeugen, aber es kommt es mir so rüber, als ob Du das nur überflogen und gedanklich weggedrückt hast. Aber wie gesagt, es kann auch nur so rüberkommen.
Wichtig: In der Option2 geht es um den richtigen Einsatz von Double-Quotes und "Backslashes".

Manche Leute scheinen doppelte Anführungszeichen zu benötigen, damit das läuft. Bei anderen (wie bei mir) arbeitet schtasks.exe erst gar nicht, wenn doppelte Anführungszeichen verwendet werden. Dabei ist es (beiden Seiten) völlig Wurscht, ob es sich um ' und " oder um zweimal " handelt. Das Problem liegt überhaupt nicht auf der AutoIt Seite, sondern in der Shell... Hier wird der exakt gleiche Befehl völlig unterschiedlich verarbeitet

Wie gesagt die Double-Quotes sind es (bei meinem Vorschlag) nicht allein.
Ich meine, dass es auf der AutoIt-Seite liegt, bzw. das ShellExecute hier eine (nicht zwei) Sonderbehandlung benötigt. Auf der Microsoft-Website (Link siehe oben) wird genau diese Sonderbehandlung ganz offiziell beschrieben.
Der einzige Unterschied zwischen AutoIt-Code und Kommandozeileneingabe liegt in der Verdoppelung der Double-Quotes bzw. wie in deinem Fall durch die Kombination von Single- und Double-Quotes ("'), damit der AutoIt-Compiler weiß das es im Code eine Zeichenkette ist. (Brauche Dir hier ja sicher nicht sagen, das es nicht AutoIt-spezifisch ist, sondern eine Eigenschaft/Regel von/in vielen Programmiersprachen ..deswegen diese Ausführung nur für die stillen Mitleser.)
Aber zurück zumThema: Wir haben ja im Grunde ein "doppeltes ShellExecute" ... eins vom AutoIt-Code in die Aufgabenplanung und dann eins aus der Aufgabenplanung auf die Aktion (wenn der Trigger ausgelöst wird). Beide müssen wissen was Programm+Pfad und Übergabeparameter sind, dehalb ist ja die Einhüllung in Double-Quotes (") ratsam.
Das ist jetzt kein Vorwurf, (ganz allgemein ausgedrückt) wenn man ein System in einer unspezifizierten Art und Weise befüttert, darf man nicht erwarten, dass auf allen System die gleiche Reaktion auftritt. Ich habe die Wahrheit nicht gepachtet .. versuche nur die beschrieben Effekte zu feststehen.

Der Befehl, der bei Palm_Maniac zu einem funktionierenden Eintrag führt, bewirkt bei mir nur einen Absturz der schtasks.exe. Anders rum führt der Befehl, der bei mir einen funktionierenden Eintrag bewirkt dazu, das bei Palm_Maniac zwar ein Eintrag erzeugt wird, der aber nicht funktioniert. Wie bitteschön soll man das durch ein paar geänderte Programmzeilen unter einen Hut kriegen? Das schließt sich komplett gegenseitig aus...

Und was bewirkt der Befehl analog zu meiner Option2 im Beispiel-Code?
Was macht den schtask nun genau? Oben heißt es "arbeitet schtask.exe erst gar nicht" (klingt nach Abweisung mit Fehler) ... hier dann ... "bewirkt bei mir einen Absturz der schatask.exe" (würde für mich ein hartes "Killen" des Prozesses heißen "es ist ein Fehler aufgetreten, die Anwendung muss geschlossen werden")

Um das so direkt zu umgehen, müsste es zwei verschiedene Versionen geben, eine die einfache Anführungszeichen und eine andere, die doppelte Anführungszeichen erzeugt, je nach dem, was benötigt wird. Und genau dass wird es von meiner Seite aus nicht geben.

Da hast Du mich noch nicht überzeugt. Ich bin noch der Überzeugung, dass es eine Variante gibt, die für alle erfolgreich funktioniert. (es sei denn im neusten Win10-Build, was wir beiden nicht haben, wurde was geändert)
Ich habe das jetzt nochmal direkt in der Kommandozeile reingehackt mit den 3 Varianten (1: EPG-Original, 2: doppelte Double-Quotes, 3: analog zu meiner Option2-Syntax). Evtl. könnt ihr dies ebenso mal tun und die Ergebnisse posten (@Palm_Maniac, @mist3xyz : auch ihr seit dazu angehalten, Achtung Admin-Rechte notwendig!)

Variante 1 (die "Pfad zerreissende") wird vom schtask genauso wie die Variante 2 (Option2-Syntax von mir) erfolgreich angenommen.
Wie sieht es bei euch aus?

Neben der Win10-Version wäre evtl. noch die Architektur wichtig, um die Testumgebungen genauer zu kennen... bei mir ist es x64.

Deswegen werde ich in Zukunft diese Funktion gar nicht mehr verwenden. Auch, aber nicht nur wegen diesem Problem. Vor allem fehlen mir einfach wichtige Einstellungsmöglichkeiten, die man per schtasks.exe nicht erzeugen kann
...
Und damit ist dieses leidige Thema hoffentlich endgültig vom Tisch. Wir können weiter darüber reden, wenn die neue Version vorliegt. Aber ich befürchte, dass dann einige Leute statt XML unbedingt JSON Dateien haben müssen, damit es funktioniert...

OT: Überlesen, weil schon mal ausführlich "durchgekaut" und hier nicht zu meiner Kernfrage gehörend. "leidiges Thema" ließt man öfters hier ... positiv Denken! .. es gibt keine Probleme nur Aufgaben
Wenn es eine andere Lösung gibt, die weitere/mehr Möglichkeiten bietet ... why not.

 

[Palm_Maniac]

Hi,

hab die 3 Varianten nochmal in die Eingabeaufforderung gehackt.

Option 1 erzeugt ja bekanntermassen den zerschossenen Eintrag auch weiterhin bei mir
Option 2 erzeugt einen richtigen Eintrag, der auch ausgeführt werden kann. Diese Option hatte ich auch bei meiner Suche nach einer Lösung gefunden.
Option 3 mit " "..." " gibt auch bei mir eine Fehlermeldung. Diese Option funktioniert nur mit " '....' ", zumindest bei mir und auch laut Hilfe von schtasks.exe

Die Windows-Version ist 10.0.15063 64Bit.