The expensive part of transcoding is encoding into h264. That doesn’t work well on the pi.
Oops previous fix was for live tv only. Pushing new build with recording playback fix.
Gotcha, tested on an Apple TV and got the same results as the iPad, original quality on both live TV gets a spinning wheel and recordings have a transcoder error. Feel free to login to my server if you need to test.
Tried the update that just released, no longer getting a transcode error for recordings but live and recorded still have black screens with a spinning wheel.
Any errors in the DVR Log?
Permission denied, everything works fine locally. Installed on the latest raspbian release and had to install ntfs through terminal for the USB HDD to be writable, does channels need to be installed on the external storage itself?
No the software should be installed on the system drive.
The permission error is probably trying to write to that ntfs mount. I imagine the same errors would occur if you tried to record something. What’s the full log message?
017/12/09 23:23:10 [TNR] Opened connection to 1321FE7D for ch807
2017/12/09 23:23:10 [HLS] Starting transcoder for channel 807 (encoder=remux, resolution=, deinterlacer=, bitrate=10000)
Could not write header for output file #0 (incorrect codec parameters ?): Permission denied
2017/12/09 23:23:20 [HLS] Stopping transcoder session ANY-ch807 @ 0s
2017/12/09 23:23:20 [TNR] Closed connection to 1321FE7D for ch807
2017/12/09 23:24:02 [HLS] Starting transcoder for file-1 at 0s (encoder=remux, resolution=, deinterlacer=, bitrate=10000)
/media/pi/Passport/DVR/Movies/Toy Story (1995) 2017-12-08-2306.mpg: Permission denied
I was able to record and watch live TV and recordings locally
Check the permissions on the DVR/Streaming directory, or delete it so the software can recreate it.
Ok, not sure whats going on… When I first connected the drive yesterday it was seen as read only so I installed the NTFS sudo apt-get install ntfs-3g at that point I could create a new folder, named it DVR and pointed channels to it. It seems like after rebooting it has become read only again. I’m not on location now and can’t remote into it so I’ll have to try something tomorrow. Thanks for the help, if you know of an easy fix for remounting the drive properly let me know!
You probably need to fix your /etc/fstab to make sure it uses ntfs-3g on reboot
Ok, I’ll read up on it, if you know a command right off let me know if not I’m sure I’ll be able to find it.
What does “mount” say?
Only access I have atm is through the DVR interface, the drive originally mounted under /media/pi/ I can access a local computer tomorrow and should be able to ssh into the pi from there to make changes
Basically you want to:
umount /media/pi
nano /etc/fstab
mount /media/pi
Everything is working fine now, I wasn’t able to mount it properly yet but was able to repeat what I did the first time so it should stay mounted until a reboot, shouldn’t need to reboot again until I get back down there with the freenas server.
A few things, I’m not sure how much of it is related to the pi being weak hardware but I assume if we get it working on the pi it will help with other devices…
I have an iPad and Apple TV both remote streaming at original quality, if two different channels are playing everything works fine. If the same channel is playing on each device and one device goes back to the guide the other device will get a buffer wheel and the channel will freeze. Also in one instance I was playing a channel on the iPad and then started playing the same channel on the Apple TV, the Apple TV started at the beginning of the iPads buffer and acted as if it was playing live, even though it was 10 mins behind it didn’t allow fast forwarding. Exiting to the guide and picking back up resolved that issue.
Recordings don’t seem to have an issue with playing different or the same recording simultaneously, they are a little slow to start with two going but I’ll chalk that up to a weak processor and only one drive plugged into a USB 2 port, should perform much better on my dedicated server.
Ah, there’s a bug where multiple remote streams of the same channel/recording don’t play well together. I guess the code assumes a single-user only so it isn’t accounting for the case where multiple devices would be watching the same thing.
I should be able to tackle the issue later this week.
The bug preventing multiple clients streaming the same channel/recording has been fixed in the latest DVR v2017.12.14.2138 pre-release. To update hold down SHIFT and click Check For Updates.
Works great