Each client has them in the same priority.
First - 192.168.110.243
Second - 192.168.110.242
Third - 192.168.110.241
Should the server have the same priority? I had the clients using the inverse priority from the server.
Server Priority:
First - 192.168.110.241
Second - 192.168.110.242
Third - 192.168.110.243
I wanted to test my old NUC (D54250WYK) and see how well it would do hardware transcoding because I didn’t like the QNAP TS-251A. At first it was working fine and I was getting great transcoding speeds (around 7-8x compared to a little over 1 with the QNAP), but then I updated to the pre-release and got these errors when trying to transcode to my iPad and iPhone:
2017/04/14 17:58:59 [HLS] Starting transcoder for channel 802 (encoder=h264_qsv, resolution=1080, deinterlacer=blend, bitrate=10000) [mpegts @ 0000000000ceb5c0] Could not find codec parameters for stream 2 (Audio: ac3 (AC-3 / 0x332D4341), 0 channels, fltp): unspecified sample rate Consider increasing the value for the 'analyzeduration' and 'probesize' options pipe:: could not seek to position 70815.661 [h264_qsv @ 0000000000e1ba80] Error during encoding: device failed (-17) Video encoding failed [aac @ 0000000000e1d6c0] 2 frames left in the queue on closing 2017/04/14 17:59:32 [HLS] Stopping transcoder session 131F8A20-ch802 @ 0s
What’s the CPU field say on the dvr settings? New build is working fine on my QNAP, so must be something with older CPUs perhaps…
4 cores / Intel® Core™ i5-4250U CPU @ 1.30GHz
I just tried to stream away from home and the DVR crashed. It restarted though.
You’ll have it in about 30 minutes.
Glad to report this build fixed my guide issues
What kind of guide issues were you having before?
It was not matching most channels.
Before the update i had MyCity-Cable and MyCity-Digital
After the update, only digital was available, but it generated the entire list.
Speeds that high are not possible, and usually mean the recording was already H.264 and was only getting remuxed.
New build available v2017.04.17.1856:
curl -XPUT http://127.0.0.1:8089/updater/check/2017.04.17.1856
Invoke-WebRequest -UseBasicParsing -Method Put http://127.0.0.1:8089/updater/check/2017.04.17.1856
The new build will print out which tuners are being used in the DVR log, so you can see whether or not they are being shared as you would expect.
Ok, 3 ATV’s all with Beta ATV. All have the same three HDHR in the same sequence and all are set to Transcode Heavy.
Tuned each of them to channel 68.1.
Looks like the first client got a tuner and started playback. The second client established a connection with the second tuner, tuned and started playback. Did not share the existing session. Third Client immediately started shared from the tuner from the second client session.
Is that expected behavior? Why would it not share the connection from the first?
Here is the log:
2017/04/17 18:35:36 [TNR] Opening connection to 1053D4DE for ch68.1
2017/04/17 18:35:59 [TNR] Opening connection to 1053D4DE for ch68.1
2017/04/17 18:36:49 [TNR] Sharing existing connection to 1053D4DE for ch68.1 (clients=2, len=0)
Also noticed that once the Sharing starts, when I go to the Status page on the web, it initially shows pretty blank, no tuners found, then it finally populates with the tuners and the rest of the content after a delay of about 8 seconds…
The only reason it wouldn’t share is if the transcoding setting was not the same.
Check the HDHR tuner status page to see what transcode setting is being used on each stream.
Checking each of the HDHR's they are all configured the same:
also went back and change the HDHR tuner priority on all clients so that they are the same as the servers.
The transcode option that’s used is the one set inside the ATV app itself.
On the HDHR web UI, under Tuner Status you can see what the streams are using. For example: Bug Report: HDHR Extend recordings do not transcode
v2017.04.17.1856 has been pushed out to everyone. Thanks for the help testing!
I improved the logging in v2017.04.19.0028 to also show the transcode mode being requested when tuner sharing is using an EXTEND.
2017/04/18 13:57:07 [TNR] Opened connection to 1050DFD6 for ch11.1 [transcode=none]
2017/04/18 13:57:26 [TNR] Closed connection to 1050DFD6 for ch11.1
Checked this morning, and I am not seeing the skipping on the tuners. Started same three AppleTVs, first one got the tuner, and the next two both opened shared streams. THANKS!!!