Search the Community

Apologies for the rather long post, but I wanted to try and present all the relevant details as far as I've been able to tell... I'm encountering a persistent issue in the recordings Emby server on my Synology NAS makes. Specifically, in a number of cases the recorded video file, at some point within its duration (no pattern as far as I can tell), will show some corruption for a brief period - anything from virtually instantaneous to on/off over a few seconds - following which the audio will be significantly out of sync with the video (more than 2-3 secs, probably even >10 secs in some cases)... this then persists for the remainder of the recording. This has been occuring for quite a while, through multiple Emby server versions - almost certainly back to before v4. The issue only affects HD channels (I have OTA Freeview in the UK, so these are all H.264/AAC full HD DVB-T2 streams) - I've never seen it happen to an SD channel recording (MPEG2/mp2 576p DVB-T). Even within that, there's a dramatic difference between the HD channels themselves... the issue impacts: - approx. 60-65% of all BBC One HD recordings (>30 tested) - approx. 55% of all BBC Two HD recordings (>15 tested) - approx. 25% of all BBC Four HD recordings (>25 tested) I had thought it wasn't impacting any recordings at all from ITV HD, Channel 4 HD or Channel 5 HD (20 tested in total) - but then yesterday I had it happen to a Channel 4 HD recording for the first time (that I can remember / since I started taking notes). Note: it is very definitely a server-side issue and not a client payback one - the problem exists regardless of whether playing back through Emby, Plex, Kodi, or just using VLC or another media player on a PC to directly play the recorded .ts file - though sometimes the problem exhibits as a complete loss of audio rather than just being many seconds out of sync. Based on my observations and troubleshooting so far, I have reached the following tentative conclusions: #1. It does *not* seem to be a signal/aerial/tuner issue Since I had previously been using Plex as my DVR solution, until they royally messed up their EPG in the UK (& I've now come to appreciate a number of other Emby advantages!), I still had/have many programmes being simultaneously recorded through Plex as well as through Emby. These record using the exact same setup as Emby: a single rooftop aerial feed into an amplifying 4-way splitter, 3 of which feed into HDHomeRun Connect tuners connected to the same gigabit switch as the NAS is connected to. I have never had the issue occur with any of the Plex recordings, so the actual broadcast signal does not exhibit the problem. To check that it wasn't a problem with a particular one of the tuner devices, or the short aerial lead between that and the splitter, I switched around so that Emby recorded using the tuners previously used by Plex and vice versa - Emby continued to have the problem while Plex's recordings remained perfect. #2. It seems to be specific to the Synology version of Emby server Since the problem was only impacting Emby and not Plex, I installed a second Emby server as a test, on a very old Windows PC I'd stopped using but not yet thrown out. Again, this records from the same HDHomeRun tuners as the NAS-based Emby & Plex. So far, I have not encountered a single occurrence of the issue. As a further test (after reinstalling the main Emby server on the NAS, per #3 below), I also installed a third Emby instance using the Docker container image (running on the NAS, and again using the same tuners, etc.). While the sample set of tested recordings from this instance is probably still only around 10 total, none of them have exhibited the issue even though some of those programmes *have* had the problem in the parallel recording by the main Synology-package Emby server. #3. It doesn't seem to be due to a corrupted Emby installation Since the PC-based test Emby server showed no problems, I thought it might just be some kind of corruption in the Emby server installation on the NAS - which has by now been upgraded through multiple versions. I therefore removed the Emby package entirely and then re-installed it (after rebooting the NAS) and restored the server config using the backup plugin* Unfortunately, this seems to have had no effect and the issue continues as before. #4. It may have some relation to broadcast TS streams without timestamps? While recently developing a post-processing script to re-mux DVR recording files from .ts into .mkv format, to get lag-free skipping when playing back via my Nvidia Shield, a significant number of files can't be converted using ffmpeg as it complains about "Timestamps are unset in a packet for stream 0" and "Can't write packet with unknown timestamp". Interestingly, this seems to be the case only for recordings from those HD channels that are impacted by the AV sync issue (though ffmpeg fails whether the recording is impacted or perfectly OK) - plus I did see the same ffmpeg errors trying to convert the one Channel 4 HD recording yesterday that exhibited the AV sync issue. Unfortunately, while I can see how the absence of timestamps might play a part in continuing the huge audio sync issue following some slight corruption, I'm not sure if it helps explain why Synology-Emby has this recording problem when none of Windows-Emby, Docker-Emby or Plex do? Can anyone help with a suggestion as to any of: what the problem might be?, a potential resolution?, or what else I might do to further diagnose the issue? Would it be worth me finding the time to completely remove & reinstall the Emby package once again, but this time manually recreate the entire configuration rather than using the backup plugin? * BTW: major kudos on the excellent server config backup plugin - it only needs the addition of restoring series & recording schedules to make it virtually perfect! (Series especially, since it's not just an annoying effort to have to recreate them, but it's simply impossible to recreate any series schedule when that show is currently between seasons and so not in the guide.)