TV-Browser-Forum

tell application "Terminal"
	do shell script ¬
		"/opt/bin/tvbrowser.sh"
	-- Falls das Terminal beendet werden soll, in der Zeile unten "--" entfernen
	--quit
end tell

Application
Sign to run locally

Verbesserte Version

[code]tell application "Terminal"
do shell script ¬
"/opt/bin/tvbrowser.sh"
-- Falls das Terminal beendet werden soll, in der Zeile unten "--" entfernen
--quit
end tell[/code]

Aus dem Script Editor exportieren als

[code]Application
Sign to run locally[/code]

do shell script ¬
	"/opt/bin/tvbrowser.sh"
quit

Application
Stay open after Run handler (das ist die mittlere Checkbox)
Sign to run locally

Hmph, da Platypus zur Zeit nur Intel 64-Bit-Binaries erstellen und damit aber kein TVB mit aarch64-Java starten kann, habe ich einen anderen Starter in AppleScript geschrieben, der das Script oben aufruft.

[code]do shell script ¬
"/opt/bin/tvbrowser.sh"
quit[/code]

Aus dem Script Editor exportieren als

[code]Application
Stay open after Run handler (das ist die mittlere Checkbox)
Sign to run locally[/code]

@ds10
4.2.4 läuft ebenfalls; dabei benutze ich weiterhin meinen Wrapper.
[b]DANKE FÜR ALLES![/b]

#!/bin/bash
# TV-Browser Wrapper w/ Calendar wrapper, by andre, 2021-12-19, v3
# USE AT YOUR OWN RISK
process="/Applications/TV-Browser.app/Contents/MacOS/JavaAppLauncher"
if pgrep -q -f ${process} ; then
  echo "Already running; quitting."
  exit 1;
fi 
open -g -a "Calendar"
${process}
osascript -e 'tell application "Calendar" to quit'
exit 0;

#!/bin/bash
# TV-Browser Wrapper w/o Calendar wrapper, by andre, 2021-12-19, v2
# USE AT YOUR OWN RISK
process="/Applications/TV-Browser.app/Contents/MacOS/JavaAppLauncher"
if pgrep -q -f ${process} ; then
  echo "Already running; quitting."
  exit 1;
fi 
${process}
exit 0;

Die neue Version startet per Doppelklick und läuft mit temurin-17.jdk aarch64 sowie mit temurin-11.jre im Rosetta-Modus.

Da es von der Kommandozeile aus, übrigens richtig ohne Zusatzparameter, funktioniert, werde ich, sobald die Beta stabil wird, auf Java 17 umstellen und folgenden Launcher per [url=https://sveinbjorn.org/platypus]Platypus-App[/url] verwenden:

[code]
#!/bin/bash
# TV-Browser Wrapper w/ Calendar wrapper, by andre, 2021-12-19, v3
# USE AT YOUR OWN RISK
process="/Applications/TV-Browser.app/Contents/MacOS/JavaAppLauncher"
if pgrep -q -f ${process} ; then
echo "Already running; quitting."
exit 1;
fi
open -g -a "Calendar"
${process}
osascript -e 'tell application "Calendar" to quit'
exit 0;
[/code]

Alternativ ohne Kalender:
[code]
#!/bin/bash
# TV-Browser Wrapper w/o Calendar wrapper, by andre, 2021-12-19, v2
# USE AT YOUR OWN RISK
process="/Applications/TV-Browser.app/Contents/MacOS/JavaAppLauncher"
if pgrep -q -f ${process} ; then
echo "Already running; quitting."
exit 1;
fi
${process}
exit 0;
[/code]

[quote=andre post_id=127284 time=1639898323 user_id=3077]Mit der offiziellen Beta1 gibt es das Problem nicht.[/quote]
Das zeigt deutlich, dass es nicht am TV-Browser-Code liegen kann, denn der unterscheidet sich zwischen der offiziellen Beta und den Testversionen, was den Start von externen Programmen angeht, gar nicht. Möglich wäre dass sich zwischen arm64 und x86_64 irgendetwas in die Quere kommt und was mir eben noch als Ursache eingefallen ist. Bisher habe ich die TV-Browser-Pakete immer in einer VM mit Mojave kompiliert, die Testpakete (und den neuen Starter) aber in einer VM mit Big Sur. Möglicherweise gelten die unterschiedlichen Pakete von TV-Browser jetzt als Programme von verschiedenen Entwicklern, was dann in der kompletten Prozesskette, die von TV-Browser ausgeht sich fortpflanzt. In Folge kommt irgendwie das System damit nicht klar.

Also habe ich das Paket jetzt nochmal unter Mojave kompiliert (Achtung der Link hier ist etwas anders):
[url]https://www.tvbrowser.org/downloads/test2/tvbrowser_4.2.3.95-Beta1_macjava.dmg[/url]
Das Paket enthält außerdem noch ein Update für die TV-Browser Protocol App, die dann auch mit arm64 läuft. Ansonsten könnten tvb://-Links nur ausführt werden, wenn auch ein x86_64-Java auf dem System wäre und TV-Browser damit nicht crasht.

Als weitere Möglichkeit fiele mir noch ein das AppleScript was du aufrufst in einer App zu speichern und die dann stattdessen aufzurufen. Im Skripteditor kann man das über Ablage->Sichern unter (wird sichtbar, wenn man die Optionstaste drückt).

[quote=ds10 post_id=127282 time=1639863803 user_id=619]
[Du könntest auch einmal die [url=https://hilfe.tvbrowser.org/viewtopic.php?f=2&t=19237]offizielle Beta[/url] runterladen und testen, ob der Kalender damit angesprochen werden kann. Die offizielle Beta läuft ja immer noch nur im x86_64-Modus, wie die 4.2.3.
[/quote]

Mit der offiziellen Beta1 gibt es das Problem nicht.

[quote=ds10 post_id=127282 time=1639863803 user_id=619]
Danke an euch beide fürs Testen, das war ja eine ziemlich harte Nuss zu knacken, aber das Startproblem ist jetzt gelöst.
[/quote]

Danke für deine Zähigkeit und deine unermüdliche Arbeit!

[quote=andre post_id=127279 time=1639862095 user_id=3077]Der Teil des Scripts, der einen Timer auf meiner Neutrino HD-Box mit curl erzeugt oder entfernt, funktioniert ja! Lediglich der Kalendereintrag (in der iCloud) will nicht.[/quote]
Und allein daran erkennt man, dass TV-Browser hier praktisch nicht das Problem sein kann, denn darüber hat TV-Browser keine Kontrolle. Das Script ruft es ja auf, wie soll da TV-Browser die Ursache sein? Allein daran, dass es in einer Endlosschleife passiert sieht man, dass das System irgend etwas anders macht, denn dein Script wird die Kalender-App auch nur einmal aufrufen und nicht in einer Schleife programmiert sein.

Der Teil von TV-Browser, der externe Programme startet wurde zwischen TV-Browser 4.2.3 und der Beta nicht geändert, nur am Parametersystem gab es Änderungen, um Bugs zu fixen. Wenn aber dort das Problem wäre, dann müsste dein Shellskript ein Problem mit den übergebenen Parametern haben und dann könntest du die Probleme auch leicht finden, indem du das Shellskript, die Parameter nummeriert, in eine Datei schreiben lässt und das Skript dann einmal mit TV-Browser 4.2.3 ausführst, die ausgegebene Datei sicherst und dann einmal mit der Beta startest. Wenn dann die Parameter unterschiedlich sein sollten, würde ich da ansetzen.

Es ist praktisch ausgeschlossen, dass TV-Browser irgend etwas tun kann, was das Problem verursacht. Der Starter möglicherweise, da der eben jetzt universal ist. Aber auch das scheint eher unwahrscheinlich, denn das Problem tritt ja in einem externen Skript auf, das den Aufruf der Kalender-App ausführt. Du könntest auch einmal die [url=https://hilfe.tvbrowser.org/viewtopic.php?f=2&t=19237]offizielle Beta[/url] runterladen und testen, ob der Kalender damit angesprochen werden kann. Die offizielle Beta läuft ja immer noch nur im x86_64-Modus, wie die 4.2.3.

Vielleicht probierst du auch einmal das Shellskript zu kopieren, umzubenennen und dann die Kopie in der Aufnahmesteuerung zu nutzen.

Letztendlich hat das hier aber nichts mehr mit dem Startproblem zu tun. Ich denke auch nicht, dass ich da wirklich helfen kann, da das mit ziemlicher Sicherheit ein Problem außerhalb von TV-Browser ist.

Danke an euch beide fürs Testen, das war ja eine ziemlich harte Nuss zu knacken, aber das Startproblem ist jetzt gelöst.

Der Teil des Scripts, der einen Timer auf meiner Neutrino HD-Box mit curl erzeugt oder entfernt, funktioniert ja! Lediglich der Kalendereintrag (in der iCloud) will nicht.
Der Pfad ist derselbe: /Applications/TV-Browser.app
Wechsle ich zurück auf die stabile Version, fragt er mich genau einmal, ob ich den Kalenderzugriff erlauben möchte, und benutzt den Kalender dann.
Wechsle ich zurück auf die Beta, fragt er mich endlos, ob ich den Kalenderzugriff erlauben möchte, bis ich Calendar.app abschieße. In den Kalender wird nichts geschrieben.

Mit dem Starter der Beta1 in der stabilen Version und zulu-11.jre aarch64 kommt keine Fehlermeldung bzgl. Kalenderzugriff, es wird aber weder etwas hinein geschrieben noch daraus gelöscht. Der Teil, der den Timer erzeugt bzw. löscht, funktioniert weiterhin.

#!/bin/bash
echo TEST > /tmp/1.txt

Du kannst ja einmal testweise den Starter aus der Beta in die Stable kopieren und dann testen, ob der Export dann noch funktioniert. Unabhängig davon kann es aber eigentlich nicht an TV-Browser liegen, es ist eine Funktion des Betriebssystems, die die Freigabe erteilt oder auch nicht. Die Aufnahmesteuerung führt einfach nur einen Programmstart aus, dazu wird letztendlich eine Java-Funktion aufgerufen, mehr kann sie auch nicht machen. Der Rest wird dann von Java ausgeführt und das läuft dann in ein Problem, das darin begründet ist, dass das Betriebssystem nicht will.

Ich habe hier in der VM einmal probiert ein Shellskript aufzurufen, das ruft dann natürlich kein AppleScript auf, sondern schreibt einfach nur das Wort TEST in eine Datei. Das funktioniert problemlos, ich bekomme auch keine Abfrage eines Sicherheitssystems, was vielleicht auch daran liegt, dass ich TV-Browser in der VM kompiliert habe und er somit nicht als vom jemand anderem erstellt gilt.

Was passiert denn bei dir, wenn du ein neues Gerät anlegst und das dann ein ganz einfaches Shellskript aufrufen lässt (man muss natürlich einen Parameter für die Aufnahme hinzufügen, aber da reicht ja [c]{title}[/c])?
[code]#!/bin/bash
echo TEST > /tmp/1.txt[/code]

[quote=andre post_id=127276 time=1639851731 user_id=3077]TVB liegt beide Male in /Applications/[/quote]
Im absolut selben Pfad? Also [c]/Applications/TV-Browser.app[/c].

Die Freigabe für den Zugriff auf den Kalender erteilt man in den Systemeinstellungen, sie ist eigentlich erteilt und die stabile Version funktioniert. Sie ist nicht dauerhaft erteilbar für die Beta 1 (Endlosschleife).
TVB liegt beide Male in /Applications/.
Getestet habe die Beta 1 gegen JRE 11 für x86_64 und aarch64 sowie gegen JDK 17 für aarch64.

[quote=andre post_id=127274 time=1639850147 user_id=3077]Wenn ich die Rosetta-Checkbox in der Beta 1 aktiviere, verlangt er ausschließlich nach Java x86_64.[/quote]
Gut, dann funktioniert das zumindest auch, so wie es soll.

[quote=andre post_id=127274 time=1639850147 user_id=3077]Gebe ich ihm x86_64, habe ich weiterhin das Gatekeeper-Problem, das ich mit der stabilen Version mit demselben Java und demselben Script nicht habe.
Nichts ist anders außer der TVB-Version. Könnte es sein, dass Recording Control 3.1.9.1 der Beta 1 irgendwo einen Fehler an die Beta 1 zurückgibt?[/quote]
Eher unwahrscheinlich, wenn du in beiden TV-Browsern dieselbe Plugin-Version verwendest. Es gab zwischen den beiden Versionen von TV-Browser zwar Änderungen am Parameter-System, aber falls das das Problem wäre, würde sich der Fehler eher innerhalb von TV-Browser abspielen und nicht auf Ebene des Betriebssystems.

Du hast ja letztendlich ein Problem, dass macOS keinen Zugriff gewährt und das ist halt der Punkt auf den TV-Browser oder das Plugin keinen Einfluss hat. Daher müsste man wissen, wo man im System die Freigabe erteilen kann. Vielleicht hat es auch damit zu tun, dass schon eine Freigabe für TV-Browser vorliegt, der aber im Pfad [c]/Applications/TV-Browser.app[/c] erwartet wird und es nicht läuft, wenn er woanders liegt.

Wenn ich die Rosetta-Checkbox in der Beta 1 aktiviere, verlangt er ausschließlich nach Java x86_64.
Gebe ich ihm x86_64, habe ich weiterhin das Gatekeeper-Problem, das ich mit der stabilen Version mit demselben Java und demselben Script nicht habe.
Nichts ist anders außer der TVB-Version. Könnte es sein, dass Recording Control 3.1.9.1 der Beta 1 irgendwo einen Fehler zurückgibt?

[quote=andre post_id=127270 time=1639845013 user_id=3077]Mit der neuesten Version wird angezeigt, dass Java 11 arm64 benötigt wird, wenn kein aarch64 vorhanden ist.[/quote]
So ist das auch gewollt. Das ist vielleicht etwas verwirrend, denn [c]/usr/libexec/java_home -V[/c] zeigt [c]arm64[/c] als Architektur an. Auf der Downloadseite von Temurin JDK, steht dann aber aarch64. Bei Azulu steht ARM 64-bit.

[quote=andre post_id=127270 time=1639845013 user_id=3077]Ich habe aber sogleich einen Bug gefunden, er betrifft die Übergabe an Calendar.app per Recording Control Plugin. Ich lasse Recording Control ein Shell Script aufrufen, das u. a. einen AppleScript-Befehl zum Ein- bzw. Austragen in einen Kalender vorsieht. Während es mit der 4.2.3.0 anstandslos funktioniert, bekomme ich mit der der Beta 1 eine Endlosschleife des Sicherheitssystems, mit der Zugang des TVB zum Kalender angefordert wird. Egal aber was ich drücke, der Dialog (Don't allow | OK) kommt immer wieder. In den Systemeinstellungen wird der Zugang jedes Mal ein- oder ausgeschaltet. Zugang zu dem Kalender in der iCloud wird nicht erteilt.[/quote]
Also dazu kann ich nichts sagen, da es sich ja offensichtlich um irgendeine Sicherheitsfunktion von macOS handelt, worauf TV-Browser keinen Einfluss hat.

Du könntest wie gesagt einmal die Informationen der TV-Browser-Beta-App öffnen und prüfen, ob dort die Möglichkeit besteht, Rosetta zu aktivieren und falls das geht und TV-Browser dann mit x86_64 läuft nochmal testen, ob das Problem dann wieder auftritt. Wenn nicht kommt sich womöglich irgendwie arm64 und x86_64 in die Quere, wenn du das Shell-Script aufrufst.

EDIT: Ich habe das Paket nochmal neu erstellt, so dass jetzt bei fehlendem Java für arm64 [c]arm64 (aarch64)[/c] als Fehlermeldung ausgegeben wird. Dann sollte es wirklich klar sein, was man benötigt. (Der Downloadlink ist derselbe wie zuvor.)

Mit der neuesten Version wird angezeigt, dass Java 11 arm64 benötigt wird, wenn kein aarch64 vorhanden ist.

Ich habe aber sogleich einen Bug gefunden, er betrifft die Übergabe an Calendar.app per Recording Control Plugin. Ich lasse Recording Control ein Shell Script aufrufen, das u. a. einen AppleScript-Befehl zum Ein- bzw. Austragen in einen Kalender vorsieht. Während es mit der 4.2.3.0 anstandslos funktioniert, bekomme ich mit der der Beta 1 eine Endlosschleife des Sicherheitssystems, mit der Zugang des TVB zum Kalender angefordert wird. Egal aber was ich drücke, der Dialog (Don't allow | OK) kommt immer wieder. In den Systemeinstellungen wird der Zugang jedes Mal ein- oder ausgeschaltet. Zugang zu dem Kalender in der iCloud wird nicht erteilt.

@andre Das ist auch korrekt so, er läuft auf arm64 Codebasis, dann kann er x86_64-Programme nicht starten, daher wird bei der Suche nach einem passenden Java geprüft, ob die benötigte Architektur vorliegt.

[quote=andre post_id=127267 time=1639833102 user_id=3077]temurin-11.jre x86_64 --> GEHT NICHT[/quote]
In dem Fall sollte die Fehlermeldung angezeigt werden, dass ein Java 11 arm64 benötigt wird.

Ich habe jetzt ein neues Paket erstellt, bei der verbose wieder deaktiviert ist, aber im Fall von Ausführung mit arm64 der zusätzliche Parameter hinzugefügt wird. Bei dem Paket wird außerdem die Ausführung mit Systemarchitektur nicht mehr erzwungen. Also könnte es jetzt unter Informationen zur App die Möglichkeit geben das Rosetta-System zu aktivieren, um den x86_64-Code auszuführen. In dem Fall sollte dann der Starter nur x86_64-Java berücksichtigen.

[url]https://www.tvbrowser.org/downloads/test3/tvbrowser_4.2.3.95-Beta1_macjava.dmg[/url]