Leider sind 2 neue Fehler hinzugekommen: zum einen wird beim Start der Film-Wiedergabe manchmal eine falsche Abspielposition angezeigt – z.B. 10 Minuten statt 2 Minuten. Sobald der Film komplett segmentiert ist und somit die Gesamtdauer des Films bekannt ist, springt die Anzeige dann wieder auf die tatsächliche Abspielposition.
Zum anderen ändert sich manchmal während der M3U8-Wiedergabe die Gesamtdauer: z.B. statt der urpsünglichen 1:30 Stunden zu 0:45 Stunden. In diesem Fall „hängt“ dann die Wiedergabe bei 0:45 Stunden.
Wir haben diesen Bug zwar ebenfalls an Apple gemeldet, aber vorab nessMediaCenter for Apple TV 1.4.3 erweitert: während der Wiedergabe wird die Film-Dauer „überwacht“ – und wenn sie sich plötzlich zu einer geringeren Dauer ändert, dann wird der Film erneut gestartet und die letzte Abspielposition wiederhergestellt.
Diese 3 Bugs lassen vermuten, dass Apple nur 2 unterschiedliche M3U8-Playlists kennt: entweder Live-Streams mit unendlicher Wiedergabe (EVENT) oder die Film-Wiedergabe (VOD, Video On Demand), bei denen der Film schon vorab komplett segmentiert wurde.
Der Medien-Server von nessViewer segmentiert Filme aber erst, wenn die Wiedergabe gestartet wurde – alle Filme segmentiert auf einer Festplatte zu speichern würde doppelten Festplatten-Speicher belegen.
Dadurch ändert sich dann im Grunde nach Fertigstellung der Film-Segmentierung der M3U8-Playlist-Typ von EVENT zu VOD. Also von unbekannter Abspieldauer bzw. unendlicher Wiedergabe zu bekannter bzw. endlicher Abspieldauer.
Laut Dokumentation der System-Bibliothek „AVFoundation“ wird das auch grundsätzlich unterstützt – leider aber nicht ohne Bugs.
Durch Rückmeldungen von Denis ist aufgefallen, dass zufällige MAC-Adressen bisher noch nicht vollständig korrekt erkannt wurden: zwar wurden seit Version 3.9.6 die meisten zufälligen MAC-Adressen korrekt erkannt, aber leider nicht alle.
Dieser Fehler wurde nun behoben.
Darüber hinaus haben wir ein paar kleinere weitere Fehler gefunden, die ebenfalls beseitigt wurden.
]]>Bisher konnte bei der Präsentation mehrerer Medien das vorige oder nächste Medium (Bild/Film) durch Wischen/Streichen auf der Siri-Touch-Oberfläche ausgewählt werden – jedoch nur bei Bildern, da bei Filmen das Streichen durch die Film-Systemroutinen abgefangen wird.
Ausserdem wurde bei der Film-Präsentation durch Doppel-Klicken auf der Touch-Oberfläche gezoomt – unabhängig von der Position (links/mitte/rechts). Dadurch wurde auch gezoomt, wenn man z.B. rechts auf der Touch-Oberfläche doppelklickte um im Film vorwärts zu springen.
Statt Wischen/Streichen auf der Siri-Touch-Oberfläche wird jetzt das Berühren der Touch-Oberfläche ausgewertet – links um das vorige Medium, rechts um das nächste Medium auszuwählen. Das funktioniert sowohl bei Bildern als auch bei Filmen.
Bei Filmen wird jetzt ebenfalls die Position auf der Touch-Oberfläche ausgewertet: nur bei Doppelklick auf der Mitte der Touch-Oberfläche wird der Film gezoomt. Bei Klicken oder Doppel-Klicken links/rechts wird im Film rückwärts/vorwärts gesprungen ohne zu zoomen.
Für die Auswertung der Position auf der Touch-Oberfläche musste zusätzlich zu den Standard-Siri-Funktionen die Game-Kontroller-Funktion genutzt werden.
Leider haben wir erst nach der Veröffentlichung dieser Version festgestellt, dass die App abstürzt sobald in den Einstellungen ein Textfeld ausgewählt wird. Hintergrund ist die Auswertung der Position auf der Touch-Oberfläche bzw. eine Routine, die die aktuelle Ansicht (MedienCenter, Medien-Präsentation, Einstellungen) ermittelt. Wir haben nach Beseitigung des Fehlers umgehend Version 1.4.1 zur Prüfung hochgeladen.
Weitere Tests haben dann leider gezeigt, dass diese Routine – die seit Jahren unverändert verwendet wird – ebenfalls einen Absturz verursacht wenn die App bei laufender Präsentation in den Hintergrund bewegt wird. Wir haben diese Routine nun überarbeitet und umgehend Version 1.4.2 zur Prüfung hochgeladen. Diese Version ist mittlerweile freigegeben.
Ausserdem haben wir bei der Film-Präsentation die Veränderung der Abspielgeschwindigkeit hinzugefügt: Filme können jetzt mit bis zu 8facher Geschwindigkeit abgespielt werden oder in Zeitlupe bis zu 4fach.
]]>Neu für den Medien-Server ist ab macOS 10.15 der integrierte Film-Segmentierer (MPEG4AppleHLS), der Filme in M3U8-Segmente zerlegt und zu dem Medien-Client (verfügbar im MedienCenter) streamt. Bisher nur als extra Installation durch den mediafilesegmenter verfügbar, hat Apple diese Funktion nun auch als System-Routine integriert.
Nach anfänglicher Begeisterung – schliesslich könnte dies sowohl VLC 2.2.8 als auch ffmpeg überflüssig machen – kam dann aber leider schnell die Ernüchterung: entgegen dem üblichen M3U8, das auch das Streamen ermöglicht wenn noch nicht der gesamte Film als Segmente zur Verfügung steht, hat Apple ein Format gewählt bei dem der gesamte Film segmentiert sein muss. Das ist zwar okay für kurze Videos (z.B. iPhone-Aufnahmen), aber z.B. Spielfilme müssten bereits vorher immer schon komplett segmentiert sein. Bei einer grossen Film-Sammlung mit z.B. 8 TB würde dies nicht nur Zeit sondern auch weitere 8 TB Festplattenplatz benötigen. Da der Medien-Server Filme aber ad hoc segmentiert und die Segmente anschliessend wieder löscht, ist diese Lösung nun also nur bei kurzen Filmen verwendbar (weil diese schnell genug segmentiert und nach dem Streamen die Segmente wieder gelöscht werden können).
Wenn die Größe eines Filmes durch die Film-Bearbeitung verändert wurde (um z.B. lästige schwarze Balken oben und unten zu entfernen), dann konnte dieser Film bisher nur gestreamt werden wenn die Breite / Höhe eine gerade Zahl war. Jetzt wird diese Inkompatibilität erkannt und entsprechend korrigiert.
Filme, die durch den Medien-Server auf einen anderen Mac gestreamt werden, werden dort durch das WebKit (HTML) präsentiert. Entgegen dem AppleTV und iPhone können die Mac-System-Routinen (AVFoundation) leider keine M3U8-Filme wiedergeben.
Das bisher verwendete WebKit ist von Apple als „deprecated“ markiert worden – wir haben also das neue WebKit integriert.
Zusätzlich haben wir die Darstellung verbessert, Zoomen integriert und die Beibehaltung der Abspiel-Geschwindigkeit (Zeitlupe oder schnellere Wiedergabe) inetgriert. Die Darstellung-Dauer bei Bildern etc. wird außerdem ebenfalls beibehalten.
Obwohl man eigentlich erwarten dürfte, dass neuere Systeme schneller werden, ist leider genau das Gegenteil der Fall. Dies mussten wir leider schon bei dem Zugriff auf die Musik-App (statt iTunes) feststellen – und das gilt ebenfalls bei der Erstellung der Vorschaubilder und Meta-Informationen.
Dadurch war das Scrollen im MedienCenter teilweise „suboptimal“ – erst durch das neue asynchrone Erstellen dieser Informationen (rechte Seite im MedienCenter) ist es ab macOS 10.15 wieder einigermaßen flüssig.
Die grösste Überraschung war bei dem Mac Mini, dass die MAC-Adresse wechselte – schon bekannt von iPhones, aber für uns bisher noch nicht bei Macs. Zumal selbst beim Start des Mac Minis keine Info angezeigt wurde – und auch das Deaktivieren wie beim iPhone fehlt?
Sinn und Zweck ist ja eigentlich, dass so die Privatsphäre besser geschützt ist wenn das Gerät versucht sich bei verschiedenen WLANs anzumelden – bei iPhone und MacBooks macht das Sinn, aber wer geht denn mit einem Mac Mini… spazieren? Und: es werden (bisher?) nur die letzten 2 Zeichen ausgetauscht… nun ja.
Da die MAC-Adresse bei nessViewer Bestandteil des Registrierungschlüssels ist, werden hier nun die letzten 2 Ziffern bei zufälligen MAC-Adressen durch „XX“ ersetzt.
Weiterhin haben wir bei nessViewer die Video-Bearbeitung verbessert – Tests mit weiteren unterschiedlichen Film-Grössen hatten gezeigt, das das Zusammenfügen von Filmen noch nicht immer optimal funktionierte.
Ach so, ja: obwohl alle unsere Produkte auch mit Rosetta optimal funktionieren, laufen nun nessMediaCenter und nessViewer nativ auf Apple Silicon M1 Prozessoren.
Und nicht zu vergessen: Apple hat ein Update von „NV Remote II“ verlangt, da die iOS App schon länger nicht mehr aktualisiert wurde.
]]>Darüber hinaus haben wir die Film-Bearbeitung verbessert, damit jetzt auch Filme mit unterschiedlicher Orientierungen (Hochformat, Querformat) besser zusammengefügt werden.
Die System-Routinen (AVFoundation) plazieren dabei leider die einzelnen Spuren jeweils oben bzw. links. Beim Zusammenfügen wird jetzt der Offset berechnet um diese Spuren zentriert zu plazieren.
Voraussetzung hierfür war das Beibehalten der Orientierung. Bisher wurde ein Film zwar auch bei Aufnahmen im Portraitmodus korrekt angezeigt nach dem Öffnen, aber nach der ersten Bearbeitung (um z.B. einen Abschnitt zu löschen) wurde der Film quer angezeigt. Und musste anschliessend einmalig nach rechts gedreht werden.
Jetzt wird diese Orientierung auch nach der Bearbeitung beibehalten. Die dafür notwendigen Änderungen sollten aber gleichzeitig auch mit weniger Code erreicht werden, was nicht ganz einfach war und mehrere Anläufe gebraucht hat. Umso erfreuter sind wir, dass das jetzt geklappt hat.
]]>Wenn ein Medien-Titel oder eine Beschreibung im MedienCenter länger ist als der verfügbare Platz, dann wird nach kurzer Zeit der restliche Text automatisch angezeigt. Also sozusagen gescrollt.
Damit das auch bei sehr grossen Bildschirmen mit hoher Auflösung flüssig dargestellt wird, wird nur der betroffene Bereich gescrollt. Der restliche Inhalt wird also während dessen nicht erneut dargestellt.
Damit das funktioniert, stellt macOS dafür Routinen zur Verfügung – und das bereits seit dem 1. Tag von macOS. Das ist quasi fundamental.
Leider hat Apple seit Catalina damit begonnen, die Funktionen dafür erst teilweise und seit Big Sur komplett zu verändern. Das Ergebnis: zwar wird der Text gescrollt, aber die restliche Darstellung… gelöscht.
Eigentlich handelt es sich dabei um einen Bug. Der Apple auch vor über 6 Monaten mitgeteilt wurde. Leider interpretiert Apple diesen Bug anders – laut Apple handelt es sich nicht um einen Fehler, sondern um „gewolltes Verhalten“ (correct behavior). Mit dem Zusatzhinweis, dass die Entwickler ja selber Routinen für eine korrekte und optimierte Darstellung entwickeln können.
Glücklicherweise haben wir es geschafft, dieses „gewollte Verhalten“ auszuschalten.
Die AppStore-Version ist seit gestern mittag in Prüfung durch Apple – wir hoffen, dass auch diese Version bald zur Verfügung gestellt werden kann.
Nach 2,5 Tagen ist nun auch die Mac App Store Version freigegeben.
Für nessViewer für Mac ist diese Anpassung des MedienCenters auch bereits implementiert, wir sitzen aber momentan noch an weiteren Verbesserungen bei der Film-Bearbeitung.
]]>Bisher wurden sowohl beim Speichern von Filmen als auch beim Export die diversen Standard-Export-Einstellungen (Presets) von Apple verwendet. Dadurch können auf einfache Weise Filme im HD- oder SD-Format oder für AppleTV / iPad / iPhone, WiFi und Cellular gespeichert werden.
Allerdings haben diese Standard-Export-Einstellungen auch einen Nachteil: weder die Datenrate noch die FPS lassen sich explizit angeben, wodurch die Filme insbesondere beim HD-Format teilweise eine sehr grosse Dateigrösse haben. Ausserdem wird standardmässig 30 FPS verwendet – auch wenn das Original nur 25 FPS hat.
Insbesondere nach der Änderung der Video-Grösse (z.B. um Ränder oben und unten zu entfernen) sind durch die Standard-Export-Einstellungen die Filme nach dem Speichern teilweise 2-4 fach so gross wie das Original. Ursache hierfür ist neben den 30 FPS eine hohe Datenrate, z.B. 7500 statt 4500 kBits/Sekunde.
In dieser Version kann jetzt nach der Auswahl des MPEG-4 Formats die Datenrate und FPS explizit angegeben werden.
Als Standardwert werden die Werte des Originals vorgegeben – es lohnt sich aber insbesondere bei längeren Filmen die Datenrate zu reduzieren. So kann z.B. bei einer zusammengefügten 30 minütigen iPhone-Aufnahme die Dateigrösse von 2 GB auf 800 MB reduziert werden. Allerdings ist es empfehlenswert anschliessend den Export zu überprüfen und ggf. verschiedene Datenraten zu probieren um ein optimales Verhältnis zwischen Qualität und Dateigrösse zu erhalten.
]]>Neben kleineren Verbesserungen bei dem Zugriff auf miniDLNA (Datum und Dauer von Videos in besser lesbarer Form, Vorschau von Videos) ist nun auch der Zugriff auf DLNA-Medien-Server ausserhalb des lokalen Netzes via VPN möglich.
Normalerweise ist dieser Zugriff via VPN nicht möglich da selbst bei der VPN-Verbindung der DLNA-Medien-Server nicht gefunden wird. Daher kann jetzt in den nessViewer App Einstellungen neben der TCP/IP-Adresse (und Port) auch der Name der Info-Datei angegeben werden – durch diese beiden Angaben ist dann der Direktzugriff auch via VPN möglich.
Diese beiden Angaben werden von nessViewer App automatisch ausgefüllt – es reicht aus in den Einstellungen einmalig einen eindeutigen Teil der TCP/IP-Adresse (z.B. „.20:“) bei „DLNA“ anzugeben und dann mit dem MedienCenter im lokalen Netz auf den DLNA-Medien-Server zuzugreifen.
Der FTP-Client der nessViewer App kann natürlich nicht nur auf den nessViewer-Medien-Server zugreifen sondern auch auf einen DLNA-Medien-Server. Voraussetzung hierfür ist nur die Eingabe des FTP-Users und Kennwortes in den Einstellungen.
Bei der Übertragung von Dateien kann jetzt nicht nur die ausgewählte Datei übertragen werden sondern auch alle Dateien eines Ordners.
Ausserdem können jetzt auch (durch das Aktion-Menü) alle Dateien in einem Ordner gelöscht werden nachdem „Datei öffnen“ ausgewählt wurde.
Mit diesen Verbesserungen ist nun eine einfachere Übertragung vieler Fotos und Filme (ggf. sogar aus der „Fotos App“) zu dem Medien-Server (oder anders herum) möglich:
1.) Ggf. Import der Fotos und Filme aus der „Fotos App“ in die nessViewer App (via Aktion-Menü bei „Datei öffnen“).
2.) Übertragung dieser Medien von nessViewer App auf den Medien-Server (via FTP-Client).
3.) Ggf. Löschen dieser Medien in der nessViewer App (via Aktion-Menü bei „Datei öffnen“).
Das Dokument nessViewer als iCloud-Alternative stammt übrigens von 2012. Bis auf die hier beschriebenen Verbesserungen (und natürlich kleineren optischen Änderungen) ist es aber nach wie vor aktuell.
]]>Zum einen wurde das Datum von Videos in einer nicht gut lesbaren Form angezeigt und die Dauer direkt dahinter. Jetzt wird das Datum lokalisiert angezeigt und die Dauer in der 2. Zeile.
Ausserdem wird jetzt für Videos eine Vorschau angezeigt. Wir haben zwar die Möglichkeit gelesen, für jedes Video ein Cover zu erstellen und die miniDLNA-Konfiguration zu ändern. Das ist uns aber zu aufwändig bei so vielen Videos.
Allerdings kann die Anzeige der Video-Vorschau ggf. 1-3 Sekunden dauern – je nach Video.
Und ganz allgemein funktionierte bei DLNA die automatische Auswahl (sowohl nach Auswahl eines Menü-Eintrages als auch nach Rückkehr zu einem höheren Level) bei der nessMediaCenter App nicht korrekt – was jetzt korrigiert wurde.
]]>Durch Dennis sind wir darauf hingewiesen worden, dass nessMediaCenter App für AppleTV nicht auf miniDLNA, installiert auf der Raspberry Pi, zugreifen kann. Zwar wurde bisher miniDLNA nicht als unterstützter DLNA / UPnP Medien-Server angegeben, aber Raspberry Pi ist ja schon alleine wegen dem günstigen Preis eine interessante Lösung.
Nachdem leider eine Leihgabe zu alt war um OpenMediaVault 4 auf ihr zu installieren, haben wir in Raspberry Pi investiert – und mussten leider bei Tests feststellen, dass zwar mit dem MedienCenter von nessMediaCenter / nessViewer für macOS auf miniDLNA zugegriffen werden kann aber nicht mit nessMediaCenter für AppleTV oder nessViewer für iOS.
Während bei macOS die DLNA-Medien-Server-Informationen synchron geladen werden, werden sie bei iOS und tvOS asynchron geladen. Während dies bei anderen DLNA-Medien-Servern kein Problem ist, wurde bei miniDLNA die Information zu langsam geladen – und dadurch funktionierte der Ablauf nicht mehr korrekt.
Wir haben daher den Code erweitert, so dass jetzt in dem asynchronen Aufruf noch einmal geprüft wird ob auf Medien zugegriffen werden kann. Durch diese Erweiterung kann jetzt auch auf die Medien von miniDLNA zugegriffen werden.
]]>Bisher hatten wir mit den Updates für macOS 15 gewartet, weil leider auch diesmal wieder Apple unseren Bug-Report bisher nicht bearbeiten hat. Und durch diesen Bug der Zugriff auf die Medien der Fotos-App unter macOS 15 fehlschlägt. Leider wurde auch mit macOS 15.1 dieser Bug nicht beseitigt, aber da Apple dieses Update nun allgemein verfügbar gemacht hat, bleibt uns leider nichts anderes übrig. Wie auch bei macOS 14 hoffen wir natürlich, dass Apple möglichst bald Zeit findet – und nicht wieder ein 1/2 Jahr braucht.
Nachtrag vom 18.12.: mittlerweile konnten wir mit Apple das Problem klären. Glücklicherweise handelt es sich nicht um einen Bug sondern nur um eine Einstellung: die ausgewählte Fotos-Mediathek muss als System-Fotomediathek festgelegt sein damit auf die Medien der Fotos-App zugegriffen werden kann.
Die wichtigste Anpassung ist die Wiedergabe der Musik und geschützten Filme durch das MedienCenter. Während unter macOS 10.14 oder älter iTunes für diese Wiedergabe verwendet wird, wird ab macOS 10.15 die Musik-App für die Wiedergabe der Musik (Musik App Steuerung) und die TV-App für die Wiedergabe geschützter Filme verwendet.
Darüber hinaus haben wir den Zugriff auf die Medien der Fotos-App neu programmiert. Bisher wurden diese Medien und dessen Struktur direkt aus der Datenbank ausgelesen – da dies aber unter macOS 10.15 nicht mehr möglich ist, wird stattdessen jetzt das System-Framework „MLMediaLibrary“ verwendet.
Das funktioniert unter macOS 14 oder älter auch sehr gut, aber leider wie gesagt noch nicht unter macOS 15.
Das HEIC-Bildformat z.B. wird jetzt offiziell unterstützt (sofern die macOS-Version dies unterstützt).
Die “Fotos App” kann zwar die Original-Dateien exportieren oder auch die Medien in einem kompatiblen Format (wobei HEIC zu JPEG umgewandelt wird), bei letzterem wird jedoch das Original-Datum nicht beibehalten.
Die Medien der “Fotos App” konnten zwar auch bisher schon in eine Medienschau importiert und dann anschliessend exportiert (oder via Drag & Drop die Original-Dateien kopiert) werden, beim Export wurden aber die Metadaten (z.B. Aufnahmeort) immer mit exportiert und das Datum nie.
Durch die neue Option “Metadaten beibehalten” können jetzt die Metadaten (inkl. Original-Datum) optional mit exportiert werden.
Und beim Import der Medien werden jetzt immer die Original-Medien importiert – diese Änderung war notwendig durch die HEIC-Unterstützung der “Fotos App”.
Mehrere Filme können in der Medienschau ausgewählt werden und dann durch das Kontextmenü (also durch Klicken auf einen der Filme mit der rechten Maustaste) zu einem Film kombiniert werden. Der neue Film wird anschliessend zur Bearbeitung im Film-Editor geöffnet.
Rotierte Filme (also z.B. iPhone-Aufnahmen im Landscape-Format) werden jetzt im Medien-Server vor dem Streamen korrekt rotiert.
Bei installiertem Apple mediafilesegmenter wird jetzt im Medien-Server vor der Verwendung geprüft ob der ausgewählte Film in kurzer Zeit segmentiert werden kann – und ansonsten gleich VLC oder ffmpeg verwendet. Bei langsamen Rechnern oder Festplatten wird bei zu langsamen Segmentieren durch den mediafilesegmenter die Anzahl der maximalen Segmente korrigiert und anschliessend berücksichtigt.
Unter macOS 10.15 (Catalina) kann momentan ffmpeg nicht verwendet werden, weil nur noch notarisierte “Programme” gestartet werden können. Daher wird jetzt ffmpeg unter Catalina erst einmal nicht verwendet bis Apple auch hierfür eine Lösung gefunden hat.
Wir werden weiter macOS 10.15 testen und ggf. Anpassungen vornehmen – z.Zt. gibt es aber wieder (wie auch schon bei macOS 10.14) diverse Probleme mit den Zugriffsrechten auf die “Fotos App” und die Steuerung anderer Programme via AppleScript. Wir können einfach nur hoffen, dass Apple diesmal nicht wieder fast ein 1/2 Jahr nach der offiziellen macOS-Veröffentlichung braucht um diese Bugs zu beseitigen.
]]>Zwar wird es noch etwas dauern bis macOS 10.14.5 verfügbar ist, wir haben aber trotzdem jetzt schon alle 64 Bit Versionen durch Apple notarisieren lassen.
Die aktualisierten Versionen können ab jetzt von der Download-Seite heruntergeladen werden – und in Zukunft werden alle neuen Versionen notarisiert.
]]>Mit dieser Version werden 2 alte Zöpfe abgeschnitten:
Mit Version 1.8 wird jetzt endlich das dunkle Erscheinungsbild von macOS 10.14 unterstützt.
Darüber hinaus kann jetzt optional in den Einstellungen und dort unter “Medien-Server” die Server-Adresse des DLNA-Medien-Servers vorgeben werden – bzw. reicht auch schon ein Teil der Server-Adresse. Wenn die Server-Adresse des DLNA-Medien-Servers z.B. 192.169.69.10:32469 lautet, dann reicht es auch schon aus “:324” einzugeben.
Bisher war der Zugriff auf den Medien-Server von nessViewer nur durch nessViewer App (auf iPad, iPhone, iPod touch), nessMediaCenter App (auf AppleTV) oder nessViewer möglich.
Ab jetzt kann auch mit nessMediaCenter auf den Medien-Server zugegriffen werden.
Dazu müssen in den Einstellungen durch “Medien-Server” der Name und das Kennwort für den Zugriff eingegeben werden. Optional kann auch die externe Adresse (bzw. Domain) und der Port angegeben werden – ansonsten wird der Medien-Server durch Bonjour automatisch gefunden.
Mit dieser Version werden 2 alte Zöpfe abgeschnitten:
Mit Version 3.9 wird jetzt endlich das dunkle Erscheinungsbild von macOS 10.14 unterstützt.
Darüber hinaus kann jetzt optional in den Einstellungen (Reiter: Center) und dort unter “Medien-Server” die Server-Adresse des DLNA-Medien-Servers vorgeben werden – bzw. reicht auch schon ein Teil der Server-Adresse. Wenn die Server-Adresse des DLNA-Medien-Servers z.B. 192.169.69.10:32469 lautet, dann reicht es auch schon aus “:324” einzugeben.
]]>Wenn in den Einstellungen die endlose Wiedergabe aktiviert wurde, dann können anschliessend Bilder und / oder Videos (ggf. mit einer zufälligen Sortierung) wiedergegeben werden und am Ende der Präsentation wieder von vorne.
Diese beiden Optionen sind z.B. hervorragend geeignet, wenn Apple TV verwendet wird um in einem Schaufenster eigene Werbung zu präsentieren. Oder auch einfach nur um Musikvideos im Hintergrund fortlaufend abzuspielen…
Ausserdem hatte uns Gerhard darauf hingewiesen, dass bei mehreren vorhandenen DLNA-Medien-Servern der Zugriff nicht wie gewünscht funktioniert. Zwar kann auf einen der DLNA-Medien-Server zugegriffen werden – aber nur auf den, der sich als Erstes meldet. Und das muss ja nicht der sein, auf den mit nessMediaCenter zugegriffen werden soll.
Daher kann man jetzt optional in den Einstellungen die Server-Adresse des DLNA-Medien-Servers vorgeben – bzw. reicht auch schon ein Teil der Server-Adresse. Wenn die Server-Adresse des DLNA-Medien-Servers z.B. 192.169.69.10:32469 lautet, dann reicht es auch schon aus “:324” einzugeben.
Wie bisher auch schon, werden die DLNA-Medien-Server über die Standard-Schnittstelle von DLNA / UPnP gesucht und (je nach den Einstellungen des jeweiligen DLNA-Medien-Servers) melden sich diese an. Das ist bei manchen Servern sehr schnell, bei manchen Servern dauert es aber auch länger.
Die verfügbaren DLNA-Medien-Server werden in den Einstellungen angezeigt, so dass man dann sieht wie viel der Server-Adresse vorgegeben werden muss um auf den Gewünschten zuzugreifen.
Neben der Darstellung der Oberfläche in einem dunklen Erscheinungsbild ist die wichtigste Änderung aus unserer Sicht, dass der Zugriff ohne Zustimmung weiter eingeschränkt wurde.
Dies betrifft z.B. sowohl die interne Kamera und das Mikrofon (nur nessViewer, wenn Video-Aufnahme aufgerufen wird) als auch den Zugriff auf Ordner wie den Bilder- & Filme-Ordner.
Ausserdem ist jetzt die Steuerung anderer Programme (via AppleEvents bzw. ScriptingBridge) ebenfalls nur nach der Zustimmung möglich.
Die Zustimmung kann in der System-Steuerung “Sicherheit” und dort in dem Reiter “Datenschutz” eingesehen und ggf. deaktiviert werden.
Eine weitere Neuerung ist, dass bei 32 Bit Programmen jetzt eine Meldung angezeigt wird, dass in Zukunft das Programm nicht mehr unterstützt werden wird und die Installation der 64 Bit Version empfohlen wird.
Da aber – zumindest mussten wir das in der Vorabversion feststellen – die Zustimmung zur Steuerung von anderen Programmen in der 32 Bit Version anscheinend nicht angezeigt wird und somit die Steuerung auch nicht funktioniert (z.B. die iTunes-Steuerung), empfehlen wir spätestens mit macOS 10.14 die 64 Bit Version.
Übrigens mussten wir leider auch feststellen, dass zumindest in der Vorabversion von macOS 10.14 die Zustimmungen auch nicht korrekt funktionieren, wenn die Programme das dunkle Erscheinungsbild unterstützen.
Zwar sind die 64 Bit Versionen für das dunkle Erscheinungsbild vorbereitet, aber vorerst wird sie (bis dieser Fehler hoffentlich behoben wurde) noch nicht unterstützt.
Nachtrag: 5 Monate nach Erscheinen von macOS 10.14 konnten alle System- und XCode-Bugs mit Apple geklärt werden.
]]>Bis zur Beseitigung dieses Bugs werden auch in den 64 Bit Versionen solche EyeTV-Archivfilme über EyeTV abgespielt (statt direkt in der Medien-Präsentation). Leider ist diese temporäre Lösung nicht in der AppStore-Version verwendbar.
Außerdem haben wir auch ein paar kleinere Fehler beseitigt, die durch die neue Version von XCode gemeldet wurden. Und auch das Internet-Angebot wurde angepasst.
Bis zur Beseitigung des Bugs in dem Apple-System-Framework werden wir nur die aktuellen Versionen aktualisieren – bei Problemen muss also die aktuelle Version manuell heruntergeladen & installiert werden.
]]>