That looks rather interesting. Thank you.
If I may ask a numpty question…what are ‘comskip’ files?
Comskip is the program that identifies the commercials in a tv recording. It creates several files which serve to identify where the commercials exist in the recordings. An edl file is one of the files created. This file allows some players, such as Kodi, to automatically skip the commercials. If you turn on commercial flagging in Channels DVR these files are created by the channels app. However, the files are not in the proper location for Kodi.
Ah, thank you. That makes sense.
I’m using Plex (without Plex Pass) for my video serving needs. Mostly it works fine(ish!) but these huge mpg files are giving it conniptions. Well, in fairness it’s not Plex’s fault, since trying to play one on the Mac from the NAS via VLC also results in stuttery/laggy play (it sort of resembles a slideshow with audio). Similar stuff encoded with h.264/h.265 plays fine, so it’s an mpg issue.
I think you mean that its a network issue, since other users with reliable network connections don’t have a problem.
My network connection is perfectly reliable, thank you. As stated, the problem doesn’t exist with similarly resolution’d mp4/m4v files encoded with Handbrake into (formally) h.264 files, and latterly h.265 files.
Well, I wouldn’t dismiss that out of hand. I did a little research and your NAS should be able to handle at least 35Mb/second writing and between 50 or 60 reading. Are you sure that your files aren’t corrupt from too slow write speed?
At least in the US over the air mpeg2 recordings average about 20 Mbit/s . The encoded h.264 files are probably less than half that data rate for the same resolution.
My crappy little wd mycloud has no problem recording and serving mpeg2 files.
If you’re in the UK and recording HD channels then they should already be in H264.
MPEG2 files are 2-3x bigger, but even the slowest arm processors have no problem reading them from disk and sending over the network.
It definitely sounds like there’s some sort of bottleneck on your NAS, either in the CPU, Network or Disk.
For the past year I have tried to use Plex as a media server, however, all attempts were disastrous, for mpegts files. Once I changed to Emby as a media server I have able been to playback on all clients without problems.
FYI, I have tried numerous times to notify Plex developers of this defiency…only to be met with resistance from Plex to resolving this issue. Even their own DVR recordings (mpegts) are unplayable on various clients.
I also understood that DVR recordings from UK sources were in h.264…but maybe we in the US are mistaken. However, even trying to play H.264 files on Plex is horrendous, at least in US, Emby is much bettter…even from a low powered NAS.
Edit: Just to add: IMO, Channels playback is the first/foremost solution of all. I only have to use Emby when I want to be able to view ALL of my recordings, no matter the source. Currently, I am trying to re-record all “old recordings” in Channels, so I can use solely Channels…rather than having to utilize a “full function” media server (like Emby or Plex).
Is it plugged in? What kind of transfer rates do you get from a network computer to your DVR?
ridiculous. A single WD Red will read/write significantly faster than the maximum speed of gigabit ethernet. Your drives are not your problem, unless they are defective/failing.
1 Like
Good to know, but that still brings us back to the fundamental issue - two files in the same location on the NAS (same share, same folder). One is mpg from Channels, one is the same file run through Handbrake and is now mp4
Playing both on the Mac locally (wired connection to the NAS, using VLC): the mpg is a slideshow with audio, the mp4 plays fine.
mpg does seem to be the defining factor.
If you copy the mpg to your computer does it play correctly?
That’s something I need to try. I’ll do so tonight. Gut feeling says it will, but we’ll see.
As others have said, it isn’t an MPG vs MP4 issue, it is a file size/network transfer issue. if you made MPG files the same size as the MP4 files, i bet you would not have a problem
Over-the-air HD in the US is about 18 Mbps, per channel after overhead, and with most channels dividing this among 1-2 sub-channels, the actual bandwidth of and individual recording is less. I first started recording MPEG-2 on ATA-100 drives almost a decade ago. You have some type of hardware or networking limitation.
if you are on a 1000 Mbps ethernet network, 18 Mbps will barely be a blip.
if you are on a wireless then you have to worry about latency & all sorts of issues that will affect the streaming higher bandwidth video.
Automatic transcoding is a dire necessity. This was one of my first draws to SageTV back in '08/'09 when ATSC first was rolling out in the US. Video is already transcoded for iOS, etc, so i do not understand the delay in transcode & replace…
EDIT
personally, i stream, over 802.11/n, ATSC MPEG-2 recordings everyday & have no issues with playback at all.
1 Like
Unfortunately I no longer have the original file that was giving me issues. However, subsequent recordings of the same series and quality (‘River Monsters’ in HD) have played ok, providing I play them via Channels DVR and not through Plex.
There was definitely something wrong with the original file but, for now, I’m filing it under ‘one of those things’.
My belief that it is an mpg/mp4 issues is simply that mpg by itself plays poorly (in Plex) whereas mp4’s of the same file (transcoded using Handbrake’s Apple TV 1080p preset) play absolutely fine.
I’d be interested to know if Channels is using its own mpg decoder, or whether it’s relying on ATV’s inbuilt abilities (as Plex does).
My network is wireless 802.11ac. The NAS is on a wired segment and connected to the Airport basestation via a gigabit switch. I’ve had no issues streaming full-res Bluray mp4 files via Plex, so I’m reasonably sure that bandwidth isn’t an issue.
To sum up this rather rambling post (sorry!): currently I think this is a non-issue. I’d certainly prefer to use Plex as my interface as I like having all my content under one app, but it’s no biggie. I may still look into that auto-transcode Applescript idea, but purely as an interesting exercise.
Thanks for all the input folks.
1 Like
Is there any updates on transcode & replace functionality for the DVR?
Not right now. There are numerous other projects ahead of that. You should know that we want it too though! So it’s still on our list.
Has this made it any closer to the top of the list?
A decade ago, before the automated re-encoding flows on SageTV, we could re-encode outside SageTV & via Finder drop it in the recordings directory with the same file name as the original & SageTV would recognize it.
Something like that would even be great with Channels, ie Channels being able to associate files re-encoded with Handbrake, etc but named the same.
Is re-encoding of existing recordings to a more efficient CODEC still "on the list"
...I ask as i approach 12 TB of MPEG-2 files 
2 Likes
That's one of the big problems I see with this product as well. It's an absolute disk pig. At the very least a nightly conversion to mp4 should be added in. Two days of DVRing sets off space alerts on my cache drives. I don't need a 100tb nas. Not yet. But I will if I keep using Channels.
1 Like