Unfortunately, 2 new bugs have been added: firstly, when starting to play the movie, an incorrect playback position is sometimes displayed – e.g. 10 minutes instead of 2 minutes. As soon as the movie is completely segmented and the total duration of the movie is known, the display jumps back to the actual playback position.
On the other hand, the total duration sometimes changes during M3U8 playback: e.g. instead of the original 1:30 hours it changes to 0:45 hours. In this case, playback “hangs” at 0:45 hours.
We have also reported this bug to Apple, but have extended nessMediaCenter for Apple TV 1.4.3: the duration of the movie is “monitored” during playback – and if it suddenly changes to a shorter duration, the movie is started again and the last playback position is restored.
These 3 bugs suggest that Apple only knows 2 different M3U8 playlists: either live streams with infinite playback (EVENT) or movie playback (VOD, Video On Demand), in which the movie has already been completely segmented in advance.
However, nessViewer’s media server only segments movies once playback has started – storing all movies segmented on a hard disk would take up twice the hard disk space.
This essentially changes the M3U8 playlist type from EVENT to VOD once the movie segmentation is complete. So from unknown or infinite playback time to known or finite playback time.
According to the documentation of the “AVFoundation” system library, this is generally supported – but unfortunately not without bugs.
Through feedback from Denis, it became apparent that random MAC addresses have not yet been completely correctly recognized: since version 3.9.6, most random MAC addresses have been recognized correctly, but unfortunately not all of them.
This error has now been fixed.
We also found a few other minor bugs that have also been fixed.
]]>Previously, when presenting multiple media, the previous or next media (picture/movie) could be selected by swiping on the Siri Touch surface – but only for pictures, as the swipe for movies is intercepted by the movie system routines.
In addition, the movie presentation was zoomed by double-pressing on the touch surface – regardless of the position (left/middle/right). This also zoomed when, for example, you double-pressed on the right side of the touch surface to skip forward in the movie.
Instead of swiping on the Siri Touch surface, touching the touch surface is now evaluated – left to select the previous medium, right to select the next medium. This works for both pictures and movies.
For movies, the position on the touch surface is now also evaluated: the movie is only zoomed if you double-press on the middle of the touch surface. Pressing or double-pressing left/right will skip backward/forward in the movie without zooming.
To evaluate the position on the touch surface, the game controller functions had to be used in addition to the standard Siri functions.
Unfortunately, it was only after the release of this version that we found out that the App crashes as soon as a text field is selected in the settings. The background is the evaluation of the position on the touch surface or rather a routine that determines the current view (media center, media presentation, settings). After eliminating the bug, we immediately uploaded version 1.4.1 for Apple review.
Unfortunately, further tests then showed that this routine – which has been used unchanged for years – also causes a crash if the App is moved to the background while a presentation is running. We have now revised this routine and immediately uploaded version 1.4.2 for Apple review. This version has now been released.
In addition, we have added the change of the playback speed to the movie presentation: movies can now be played at up to 8x speed or in slow motion up to 4x.
]]>New for the media server for macOS 10.15 and newer is the integrated movie segmenter (MPEG4AppleHLS), which breaks down movies into M3U8 segments and streams them to the media client (available in the MediaCenter). Previously only available as an extra installation through the mediafilesegmenter, Apple has now also integrated this function as a system routine.
After initial enthusiasm – after all, this could make both VLC 2.2.8 and ffmpeg superfluous – the disillusionment quickly followed: contrary to the usual M3U8, which also enables streaming if the entire movie is not yet available as segments, Apple has chossen a format in which the entire movie must be segmented. This is okay for short videos (e.g. iPhone recordings), but e.g. cinema movies would always have to be completely segmented beforehand. With a large movie collection of e.g. 8 TB, this would not only take time but also require another 8 TB of hard drive space. Since the media server segments movies ad hoc and then deletes the segments again, this solution can only be used for short movies (because these are segmented quickly enough and the segments can be deleted again after streaming).
If the size of a movie was changed during movie editing (e.g. to remove annoying black bars at the top and bottom), then this movie could only be streamed if the width / height is an even number. This incompatibility is now recognized and corrected accordingly.
Movies streamed to another Mac through the media server are presented there through the WebKit (HTML). Unfortunately, unlike the AppleTV and iPhone, the Mac system routines (AVFoundation) can not play M3U8 movies.
The WebKit used so far has been marked as “deprecated” by Apple – so we have integrated the new WebKit.
In addition, we have improved the display, integrated zooming and the preservation of the playback speed (slow motion or faster playback). The display duration for images etc. is also retained.
Unfortunately, while one might expect newer systems to be faster, the exact opposite is the case. Unfortunately, we already noticed this when accessing the Music App (instead of iTunes) – and this also applies to the creation of the preview images and meta information.
As a result, scrolling in the MediaCenter was sometimes “suboptimal” – only with the new asynchronous creation of this information (right side in the MediaCenter) is it somewhat smooth again for macOS 10.15 and newer.
The biggest surprise with the Mac Mini was that the MAC address changed – already known from iPhones, but not yet for us with Macs. Especially since no info was displayed even when starting the Mac Mini – and also the deactivation as with the iPhone is missing?
The point and purpose is actually that privacy is better protected if the device tries to log into different WLANs – this makes sense with iPhone and MacBooks, but who goes for a walk with a Mac Mini? And: only the last 2 characters are (so far?) exchanged … well, okay.
Since the MAC address is part of the registration key with nessViewer, the last 2 digits of random MAC addresses are now replaced by “XX”.
We have also improved video editing at nessViewer – tests with other different video sizes had shown that the merging of movies did not always work optimally.
Oh, yes: although all of our products also work optimally with Rosetta, nessMediaCenter and nessViewer now run natively on Apple Silicon M1 processors.
And not to forget: Apple has requested an update of “NV Remote II” because the iOS app has not been updated for a long time.
]]>In addition, we have improved the movie editing so that movies with different orientations (portrait, landscape) can now be joined together in a better way.
The system routines (AVFoundation) unfortunately place the individual tracks at the top or left. When joining, the offset is now calculated in order to place these tracks centered.
The prerequisite for this was maintaining the orientation. Up to now, a movie was displayed correctly after opening, even if recorded in portrait mode, but after the first editing (e.g. to delete a section) the movie was displayed horizontally. And then had to be rotated to the right once.
Now this orientation is retained even after editing. The changes required for this should also be achieved with less code at the same time, which was not easy and took several attempts. We are all the more pleased that it has now worked.
]]>If a media title or description in the MediaCenter is longer than the available space, the rest of the text will be displayed automatically after a short time. Means scrolled, so to speak.
So that this is displayed smoothly even on very large screens with high resolution, only the affected area is scrolled. The rest of the content is not displayed again during this time.
To make this work, macOS provides routines for this – and has been doing this since the 1st day of macOS. That is basically fundamental.
Unfortunately, since Catalina, Apple has started to change the functions for this only partially and since Big Sur completely. The result: the text is scrolled, but the rest of the display … is deleted.
Actually this is a bug. Apple was also notified over 6 months ago. Unfortunately, Apple interprets this bug differently – according to Apple, it is not a bug, but “correct behavior”. With the additional hint that the developers may develop their own routines for a correct and optimized display.
Fortunately, we managed to turn this “correct behavior” off.
The AppStore version is in review by Apple since midday yesterday – we hope that this version will be available soon as well.
After 2.5 days, this version is now available in the Mac App Store as well.
This adjustment of the MediaCenter has already been implemented for nessViewer for Mac, but we are currently working on further improvements in movie editing.
]]>So far, the various standard export settings (presets) from Apple have been used both for saving and for exporting movies. This makes it easy to save movies in HD or SD format or for AppleTV / iPad / iPhone, WiFi and Cellular.
However, these standard export settings also have a disadvantage: neither the data rate nor the FPS can be specified explicitly, which means that the movies sometimes have a very large file size, especially in the HD format. In addition, 30 FPS is used by default – even if the original only has 25 FPS.
Especially after changing the video size (e.g. to crop the top and bottom edges), the standard export settings mean that the movies are sometimes 2-4 times as large as the original after saving. In addition to the 30 FPS, this is due to a high data rate, e.g. 7500 instead of 4500 kBits / second.
In this version, after selecting the MPEG-4 format, the data rate and FPS can now be specified explicitly.
The default values are the values of the original – but it is worthwhile to reduce the data rate, especially for longer movies. E.g. for a merged 30 minutes iPhone recording, the file size can be reduced from 2 GB to 800 MB. However, it is advisable to check the export afterwards and, if necessary, to try different data rates in order to obtain an optimal relationship between quality and file size.
We have made a video showing the editing of movies with the 64 bit version containing: rotate & save, join, delete & save, export.
]]>In addition to minor improvements in accessing miniDLNA (date and duration of videos in a more readable form, preview of movies), the access of DLNA media servers outside the local network is now also possible via VPN.
Normally this access via VPN is not possible because the DLNA media server is not found even with the VPN connection. Therefore, in addition to the TCP/IP address (and port), the name of the info file can now be specified in the nessViewer App settings – with these two details, direct access is also possible via VPN.
These two details are filled in automatically by nessViewer App – it is sufficient to enter a unique part of the TCP/IP address (e.g. “.20:”) at “DLNA” in the settings and then to access with the MediaCenter the DLNA media server in the local network.
The FTP client of the nessViewer App can of course not only access the nessViewer media server but also a DLNA media server. The only prerequisite for this is the input of the FTP user and password in the settings.
When transferring files, not only the selected file can now be transferred, but also all files in a folder.
In addition, all files in a folder can now be deleted (via the action menu) after “Open File” has been selected.
With these improvements, it is now easier to transfer many photos and movies (possibly even from the “Photos App”) to the media server (or vice versa):
1.) If necessary import photos and movies from the “Photos App” into nessViewer App (via the action menu at “Open File”).
2.) Transfer this media from the nessViewer App to the media server (via FTP client).
3.) If necessary delete these media in the nessViewer App (via the action menu at “Open File”).
There is a PDF document describing nessViewer as an iCloud alternative in German from 2012. Except for the improvements described here (and of course minor visual changes), it is still up to date.
]]>On one hand, the date of videos was displayed in an illegible form and the duration directly behind it. Now the date is displayed localized and the duration in the 2nd line.
In addition, a preview is now displayed for videos. We have read the opportunity to create a cover for each video and to change the miniDLNA configuration. But that is too complex for us with so many videos.
However, the video preview may take 1-3 seconds to display – depending on the video.
And in general, the automatic selection did not work correctly with DLNA (both after selecting a menu entry and after returning to a higher level) – which has now been corrected.
]]>We have been informed by Dennis that nessMediaCenter App for AppleTV can not access miniDLNA installed on the Raspberry Pi. So far, miniDLNA has not been specified as supported DLNA / UPnP media server, but Raspberry Pi is an interesting solution because of the low price.
After a loan was unfortunately too old to install OpenMediaVault 4 on it, we invested in Raspberry Pi – and unfortunately we had to find out during tests that miniDLNA can be accessed with the MediaCenter of nessMediaCenter / nessViewer for macOS but not with nessMediaCenter for AppleTV or nessViewer for iOS.
While the DLNA media server information is loaded synchronously on macOS, it is loaded asynchronously on iOS and tvOS. While this is not a problem with other DLNA media servers, the information was loaded too slowly with miniDLNA – and as a result the process no longer worked correctly.
We have therefore extended the code so that it is now checked again in the asynchronous call whether media can be accessed. With this extension the media of miniDLNA can now be accessed.
]]>So far, we had been waiting with the updates for macOS 15, because unfortunately (again this time) Apple has not reacted to our bug report. And through this bug, the access to the media of the Photos App fails with macOS 15. Unfortunately, this bug was not fixed even with macOS 15.1, but since Apple made this update now generally available, we have no other choice. As with macOS 14, we hope that Apple will find time as soon as possible – and will not need 1/2 year as last time.
Addendum from 18.12: meanwhile we were able to clarify the problem with Apple. Fortunately it is not a bug, but just a setting: the selected photo library must be set as a system photo library so that the photos app media can be accessed.
The most important adaptation is the playback of the music and protected movies through the MediaCenter. While macOS 10.14 or earlier uses iTunes for this playback, macOS 10.15 uses the Music App for music playback (Music App Control) and the TV app for playing protected movies.
In addition, we have newly developed the access to the media of the Photos App. Previously, these media and their structure were read directly from the database – but since this is no longer possible under macOS 10.15, the system framework “MLMediaLibrary” is now used instead.
This works very well for macOS 14 or older, but unfortunately, as already said, not yet on macOS 15.
The HEIC image format e.g. is now officially supported (if the macOS version supports it).
Although the “Photos App” can export the original files or the media in a compatible format (converting HEIC to JPEG), the latter will not preserve the original date.
Although the media of the “Photos App” could already be imported into a media show and then subsequently exported (or the original files dragged & dropped), but the metadata (e.g. recording location) were always exported and the date never.
With the new option “Keep metadata” the metadata (including original date) can now be optionally exported.
And when importing the media, the original media are always imported – this change was necessary due to the HEIC support of the “Photos App”.
Several movies can be selected in the media show and then combined via contextual menu (by right-clicking on one of the movies). The new movie will then be opened in the movie editor for editing.
Rotated movies (such as iPhone recordings in landscape format) are now properly rotated in the media server before streaming.
If the Apple mediafilesegmenter is installed, it will now be checked in the media server if the selected movie can be segmented in a short time before using it – and otherwise VLC or ffmpeg is used. On slow computers or hard disks, the number of maximum segments is corrected and then taken into account if the mediafilesegmenter is segmenting too slowly.
Under macOS 10.15 (Catalina) ffmpeg can not be used at the moment because only notarized “applications” can be started. Therefore ffmpeg is now not used under Catalina until Apple has also found a solution for this.
We will continue to test macOS 10.15 and make adjustments if necessary. But there are again (as with macOS 10.14) various problems with the access rights to the “Photos App” and the control of other applications via AppleScript. We can only hope that this time Apple will not need again almost half a year after the official macOS release to fix these bugs.
]]>Although it will take a while until macOS 10.14.5 is available, we still have all 64 bit versions now notarized by Apple.
The updated versions can now be downloaded from the download page – and in the future, all new versions will be notarized.
]]>With this version, 2 old braids are cut off:
Version 1.8 finally supports the dark appearance of macOS 10.14.
In addition, the server address of the DLNA media server can now optionally be specified in the preferences and there at “Media Server” – even a part of the server address is sufficient. If the server address of the DLNA media server is e.g. 192.169.69.10:32469, then it is enough to enter “:324”.
Previously, access to the media server of nessViewer was only possible through nessViewer App on iPad, iPhone, iPod touch or nessMediaCenter App on AppleTV or nessViewer.
From now on, the media server can also be accessed on another Mac with nessMediaCenter.
For this purpose, the name and password for the access must be entered in the preferences by “Media Server”. Optionally the external address (or domain) and the port can be specified – otherwise the media server will be found automatically by Bonjour.
With this version, 2 old braids are cut off:
Version 3.9 finally supports the dark appearance of macOS 10.14.
In addition, the server address of the DLNA media server can now optionally be specified in the preferences (tab: Center) and there at “Media Server” – even a part of the server address is sufficient. If the server address of the DLNA media server is e.g. 192.169.69.10:32469, then it is enough to enter “:324”.
]]>If endless playback has been activated in the settings, then pictures and / or videos (possibly with a random sorting) can be presented and at the end of the presentation again from the beginning.
These two options are e.g. great for using Apple TV to showcase your own ads in a shop window. Or just to play music videos in the background continuously…
In addition Gerhard pointed out to us that with several existing DLNA media servers, the access does not work as desired. Although one of the DLNA media servers can be accessed – but only the one who reports first. And that does not have to be the one which is to be accessed with nessMediaCenter.
Therefore, you can now optionally specify the server address of the DLNA media server in the settings – even a part of the server address is sufficient. If the server address of the DLNA media server is e.g. 192.169.69.10:32469, then it is enough to enter “:324”.
As before, the DLNA media servers are searched for via the standard interface of DLNA / UPnP and (depending on the settings of the respective DLNA media server) they register. This is very fast for some servers, but for some servers it takes longer.
The available DLNA media servers are displayed in the settings, so that one then sees how much of the server address must be specified in order to access the desired.
In addition to displaying the interface in a dark appearance, the most important change from our point of view is that access without consent has been further restricted.
This concerns e.g. both the internal camera and the microphone (only nessViewer if video recording will be opened) as well as access to folders such as the pictures & movies folder.
In addition, the control of other applications (via AppleEvents or ScriptingBridge) is now only possible after approval.
The approval can be viewed in the system preferences “Security” and there in the tab “Privacy” and deactivated if necessary.
Another change is that 32 bit applications now display a message indicating that the application will no longer be supported in the future and the installation of the 64 bit version is recommended.
But since – at least we had to note that in the pre-release version – the approval for the control of other applications does not seem to be displayed in the 32 bit version and thus the control does not work (e.g. the iTunes control), we recommend the 64 bit version the latest with macOS 10.14.
Incidentally, we unfortunately also had to note that, at least in the pre-release version of macOS 10.14, the approvals also do not work properly if the applications support the dark appearance.
Although the 64 bit versions are prepared for the dark appearance, for the time being it will not be supported (until this hopefully has been fixed).
Addendum: 5 month after the release of macOS 10.14, all system and XCode bugs could be resolved with Apple.
]]>Until the bug will be fixed, EyeTV archive movies are played in EyeTV (instead of directly in the media presentation) in the 64-bit versions. Unfortunately, this temporary solution is not usable in the Mac App Store version.
We also fixed a few minor bugs reported by the new version of XCode. And also the internet offer has been adjusted.
Until the bug will be fixed in the Apple system framework, we will only update the current versions – so if you encounter problems, you will need to manually download & install the latest version.
]]>