Tvheadend plugin for Emby - Beta 1

[fc7 123]

There is another streaming posibility tvheadend offers: streaming using the own HTSP protocoll. This makes it necessary that emby gives me the possibility to direct stream into its ffmpeg. Currently only HTTP and FILE access is possible.

 

Sorry @@Luke I had this answer from Tolotos in mind, from last January.

 

Maybe we can have another look into it.

 

I was thinking about the possibility to actually use Emby's DVR subsystem to do the actual recording using TVH only as a source for the stream to be recorded. So Emby would manage the recording scheduling, the actual recording of the http stream provided by TVH and the recorded asset directly. But I'm not sure the hooks are there for this to work.

 

Would this be doable?

 

 

Sent from my iPad using Tapatalk

Edited July 5, 2016 by fc7

[pünktchen 1258]

Sorry @@Luke I had this answer from Tolotos in mind, from last January.

 

Maybe we can have another look into it.

 

I was thinking about the possibility to actually use Emby's DVR subsystem to do the actual recording using TVH only as a source for the stream to be recorded. So Emby would manage the recording scheduling, the actual recording of the http stream provided by TVH and the recorded asset directly. But I'm not sure the hooks are there for this to work.

 

Would this be doable?

 

 

Sent from my iPad using Tapatalk

A quick Google search says TVHeadend can act as a Sat-IP server. A Sat-IP server can be used in Emby similar to a HDHomerun device. So using Emby's core tv with TVHeadend streams should be doable already.

[fc7 123]

A quick Google search says TVHeadend can act as a Sat-IP server. A Sat-IP server can be used in Emby similar to a HDHomerun device. So using Emby's core tv with TVHeadend streams should be doable already.

Well that is very superficial. I mean TVH works loke that in a way but for example I think Emby uses DLNA with the HDHR which I don't think TVH provides. And then there are tons of other details.

 

 

Sent from my iPhone using Tapatalk

[Luke 37071]

Actually newer sat/ip servers support streams through upnp which emby picks up on, however, for us it's very primitive at this time due to limited support for it, therefore not many users who can help test it.

[Luke 37071]

But if any of you guys have this then we can work on improving it.

[rubenverhoef 11]

Sorry @@Luke I had this answer from Tolotos in mind, from last January.

 

Maybe we can have another look into it.

 

I was thinking about the possibility to actually use Emby's DVR subsystem to do the actual recording using TVH only as a source for the stream to be recorded. So Emby would manage the recording scheduling, the actual recording of the http stream provided by TVH and the recorded asset directly. But I'm not sure the hooks are there for this to work.

 

Would this be doable?

 

 

Sent from my iPad using Tapatalk

 

That's exactly what i mean

 

I use TVH only for decrypting the channels with my smartcard. My TVH setup (FreeNAS) has a big bug with "streaming" of recorded programs not working (not a emby problem) and cause high CPU uses until a restart.

I like the Emby infrastructure and want to use this for my TV streaming in and outside my house. Sadly the HDHomerun does not support encrypted channels so i have to use TVH or other software to decrypt the channels and push it to Emby. Now i push my live tv to Emby with a M3U playlist file from TVH, it works but the TVH plugin is working faster and also supports multiple audio and subtitle streams. I also want to have a look at the Android TV Live Channels implementation for Emby when I see some free time and everything is working fine.

 

Now i use Kodi to stream live tv to my tv which uses the HTSP implementation (direct stream)  and i use Emby for streaming live tv to my mobile devices inside and outside my house.

[gedl 0]

Hi,

 

I am using TVHeadClient 4.0.9 (HTSP version 20) with Emby  Version 3.0.5984.0

 

The list of channels loads OK, but they don't show any content. I've posted my log here: http://pastebin.com/Z8AVjzh4

 

Am I missing something ?

Edited July 6, 2016 by gedl

[Luke 37071]

make sure you have guide data in TVHeadEnd because that's where the plugin will get it from.

[Cam1878 0]

I'm having an issue with the TVheadend client that I can't figure out myself.

 

The automatic guide refresh does not load any guide data.

The only time it works is immediately after an emby restart.

 

Here is trimmed down portions of my server log with debugging on.

 

Working as intended after a server restart + manually clicking the refresh button:

2016-08-03 11:43:50.7681 Info TaskManager: Executing Refresh Guide
2016-08-03 11:43:50.7754 Debug App: Refreshing guide from TVHclient LiveTvService
2016-08-03 11:43:50.7872 Info App: [TVHclient] HTSConnectionHandler.ensureConnection() : create new HTS-Connection
2016-08-03 11:43:50.7885 Info App: [TVHclient] HTSConnectionHandler.ensureConnection: Used connection parameters: TVH Server = '192.168.0.4'; HTTP Port = '9981'; HTSP Port = '9982'; User = 'emby'; Password set = 'True'
2016-08-03 11:43:50.7902 Info App: [TVHclient] HTSConnectionAsync.open: IPEndPoint = '192.168.0.4:9982'; AddressFamily = 'InterNetwork'
2016-08-03 11:43:50.7902 Info App: [TVHclient] HTSConnectionAsync.open: socket connected.
2016-08-03 11:43:50.7947 Info App: [TVHclient] HTSConnectionAsync.authenticate: start
2016-08-03 11:43:50.8188 Info App: [TVHclient] HTSConnectionAsync.authenticate: getDiskSpace don't deliver required field 'freediskspace' - htsp wrong implemented on tvheadend side.
2016-08-03 11:43:50.8188 Info App: [TVHclient] HTSConnectionAsync.authenticate: getDiskSpace don't deliver required field 'totaldiskspace' - htsp wrong implemented on tvheadend side.
2016-08-03 11:43:50.8188 Info App: [TVHclient] HTSConnectionAsync.authenticate: authenticated = True
2016-08-03 11:43:50.8188 Info App: [TVHclient] HTSConnectionHandler.ensureConnection: connection established True
2016-08-03 11:43:51.3282 Info App: [TVHclient] ChannelDataHelper: Adding channel 
<ADDS ALL THE CHANNELS>
2016-08-03 11:43:51.3929 Info App: [TVHclient] GetProgramsAsync, ask TVH for events of channel '24470462'.
2016-08-03 11:43:52.0053 Info App: [TVHclient] GetEventsResponseHandler.handleResponse: received answer from TVH server
<LISTS ALL THE GUIDE DATA>
2016-08-03 11:46:19.1810 Info App: Loading live tv data from /var/lib/emby-server/data/livetv/seriestimers
2016-08-03 11:46:19.1810 Debug JsonSerializer: Deserializing file /var/lib/emby-server/data/livetv/seriestimers.json
2016-08-03 11:46:19.1849 Info TaskManager: Refresh Guide Completed after 2 minute(s) and 28 seconds
2016-08-03 11:46:19.1853 Info ServerManager: Sending web socket message ScheduledTaskEnded
2016-08-03 11:46:19.1853 Info TaskManager: ExecuteQueuedTasks

Here is what happens later during a scheduled refresh:

2016-08-03 12:43:31.8346 Info TaskManager: IntervalTrigger fired for task: Refresh Guide
2016-08-03 12:43:31.8346 Info TaskManager: Queueing task RefreshChannelsScheduledTask
2016-08-03 12:43:31.8346 Info TaskManager: Executing Refresh Guide
2016-08-03 12:43:31.8361 Debug App: Refreshing guide from TVHclient LiveTvService
2016-08-03 12:43:31.8361 Info App: [TVHclient] ChannelDataHelper: Adding channel 
<ADDS ALL THE CHANNELS>
2016-08-03 12:43:31.8490 Info App: Refreshing guide with 14 days of guide data
2016-08-03 12:43:31.8490 Info App: [TVHclient] GetProgramsAsync, ask TVH for events of channel '24470462'.
2016-08-03 12:48:31.8491 Info App: [TVHclient] GetProgramsAsync, timeout during call for events of channel '24470462'.
2016-08-03 12:48:31.8491 Info App: [TVHclient] GetProgramsAsync, ask TVH for events of channel '118125104'.
2016-08-03 12:48:31.8491 Error App: [TVHclient] SendingHandler caught exception : System.Net.Sockets.SocketException: The socket has been shut down
  at System.Net.Sockets.Socket.Send (System.Byte[] buffer) <0x4061fb50 + 0x000bf> in <filename unknown>:0 
  at TVHeadEnd.HTSP.HTSConnectionAsync.SendingHandler () <0x4061b130 + 0x0008b> in <filename unknown>:0 
2016-08-03 12:48:31.8509 Error App: [TVHclient] HTSConnectionHandler recorded a HTSP error: The socket has been shut down
	*** Error Report ***
	Version: 3.0.6020.0
	Command line: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -ffmpeg /usr/bin/ffmpeg -ffprobe /usr/bin/ffprobe -restartpath /usr/lib/emby-server/restart.sh
	Operating system: Unix 4.1.17.6
	Processor count: 4
	64-Bit OS: True
	64-Bit Process: True
	Program data path: /var/lib/emby-server
	Mono: 4.2.1 (Stable 4.2.1.102/6dd2d0d Thu Dec  3 04:04:55 UTC 2015)
	Application Path: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe
	The socket has been shut down
	System.Net.Sockets.SocketException
	  at System.Net.Sockets.Socket.Send (System.Byte[] buffer) <0x4061fb50 + 0x000bf> in <filename unknown>:0 
	  at TVHeadEnd.HTSP.HTSConnectionAsync.SendingHandler () <0x4061b130 + 0x0008b> in <filename unknown>:0 
2016-08-03 12:53:31.8490 Info App: [TVHclient] GetProgramsAsync, timeout during call for events of channel '118125104'.
2016-08-03 12:53:31.8490 Info App: [TVHclient] GetProgramsAsync, ask TVH for events of channel '313293156'.
...and continues timeing out ever 5 minutes for all channels
2016-08-03 14:23:31.8521 Info App: [TVHclient] GetProgramsAsync, timeout during call for events of channel '1838688081'.
2016-08-03 14:23:31.8521 Info App: [TVHclient] GetProgramsAsync, ask TVH for events of channel '2068258027'.
2016-08-03 14:28:31.8521 Info App: [TVHclient] GetProgramsAsync, timeout during call for events of channel '2068258027'.
2016-08-03 14:28:31.8521 Debug App: Refreshing guide from Emby
2016-08-03 14:28:31.8521 Info App: Refreshing guide with 14 days of guide data
2016-08-03 14:28:31.8646 Debug App: Deleting item, Type: LiveTvProgram, Name: Alaska State Troopers, Path: , Id: a26e0a00-4e89-450f-26f4-9f15b83b2404
2016-08-03 14:28:31.8646 Debug App: Deleting path /var/lib/emby-server/metadata/livetv/a26e0a004e89450f26f49f15b83b2404
2016-08-03 14:28:31.8750 Debug App: Deleting item, Type: LiveTvProgram, Name: Big Brother, Path: , Id: c7341500-314c-afc0-da82-f437968789ab
2016-08-03 14:28:31.8750 Debug App: Deleting path /var/lib/emby-server/metadata/livetv/c7341500314cafc0da82f437968789ab
2016-08-03 14:28:31.8897 Debug App: Deleting item, Type: LiveTvProgram, Name: Paid Programming, Path: , Id: 7da41e00-7786-b504-5e3c-b95d5301d195
2016-08-03 14:28:31.8897 Debug App: Deleting path /var/lib/emby-server/metadata/livetv/7da41e007786b5045e3cb95d5301d195
2016-08-03 14:28:31.8982 Debug App: Deleting item, Type: LiveTvProgram, Name: Justice for All With Judge Cristina Pérez, Path: , Id: c61e3800-1d98-27ee-9f8d-be4cd9eba9e6
2016-08-03 14:28:31.8982 Debug App: Deleting path /var/lib/emby-server/metadata/livetv/c61e38001d9827ee9f8dbe4cd9eba9e6
2016-08-03 14:28:31.9142 Debug App: Deleting item, Type: LiveTvProgram, Name: Modern Family, Path: , Id: ea293800-5cd3-c906-844d-fe33f0daf519
2016-08-03 14:28:31.9142 Debug App: Deleting path /var/lib/emby-server/metadata/livetv/ea2938005cd3c906844dfe33f0daf519
....etc
2016-08-03 14:30:22.4398 Debug App: Deleting item, Type: LiveTvProgram, Name: Arthur, Path: , Id: 1634faff-2468-27eb-3536-fc2a86c1c622
2016-08-03 14:30:22.4398 Debug App: Deleting path /var/lib/emby-server/metadata/livetv/1634faff246827eb3536fc2a86c1c622
2016-08-03 14:30:22.4481 Debug App: Deleting item, Type: LiveTvProgram, Name: Coronation Street, Path: , Id: 4eedffff-d82f-9323-354c-2663c4023a7b
2016-08-03 14:30:22.4481 Debug App: Deleting path /var/lib/emby-server/metadata/livetv/4eedffffd82f9323354c2663c4023a7b
2016-08-03 14:30:22.5167 Info TaskManager: Refresh Guide Completed after 106 minute(s) and 50 seconds
2016-08-03 14:30:22.5172 Info ServerManager: Sending web socket message ScheduledTaskEnded
2016-08-03 14:30:22.5172 Info TaskManager: ExecuteQueuedTasks

If I go to the TV guide page, all the channels appear there properly, however there is no program information.

 

Does anyone know why the socket to the tvheadend server is being closed? I'm not sure if it closes the socket because of the timeout, or if it times out because the socket is closed.

 

Any help would be appreciated.

 

Thanks

Edited August 3, 2016 by Cam1878

[Cam1878 0]

As a workaround I've set it so the guide refresh happens on application startup rather than every X number of hours and set cron to restart the Emby server every 24 hours.

 

Not the best solution, but it works.

[Luke 37071]

It looks like the plugin keeps a socket connection open with tvheadend and if it disconnects it will need to handle that and reconnect without having to restart the server.

[Cam1878 0]

On an unrelated topic, I've found another issue while using the Tvheadend client.

 

I use an HDHomeRun as my antenna receiver connected to Tvheadend.

 

The transcoding function is not working well at all when playing a channel via Tvheadend, but functions perfectly when I play it direct to Emby from the HDHomeRun.

 

Ideally I'd like Emby to use Tvheadend rather than directly from the HDHomeRun since I use Tvheadend with my Kodi clients; I want recordings all in one place.

 

Here is the transcode log when playing directly from the HDHomeRun -> Emby:

http://pastebin.com/raw/Bdbf8V4Z

 

Here is the log when playing the same channel from HDHomeRun -> Tvheadend -> Emby:

http://pastebin.com/raw/L3LyA476

 

Any suggestions on why the stream is becoming so broken when routed via Tvheadend?

 

I've tried multiple streaming profiles by changing Emby's user settings on Tvheadend. This particular case was using the default htsp stream setting, but the same result occurs when using a passthrough mpegts stream or an mkv stream.

Edited August 4, 2016 by Cam1878

[Luke 37071]

On an unrelated topic, I've found another issue while using the Tvheadend client.

 

I use an HDHomeRun as my antenna receiver connected to Tvheadend.

 

The transcoding function is not working well at all when playing a channel via Tvheadend, but functions perfectly when I play it direct to Emby from the HDHomeRun.

 

Ideally I'd like Emby to use Tvheadend rather than directly from the HDHomeRun since I use Tvheadend with my Kodi clients; I want recordings all in one place.

 

Here is the transcode log when playing directly from the HDHomeRun -> Emby:

http://pastebin.com/raw/Bdbf8V4Z

 

Here is the log when playing the same channel from HDHomeRun -> Tvheadend -> Emby:

http://pastebin.com/raw/L3LyA476

 

Any suggestions on why the stream is becoming so broken when routed via Tvheadend?

 

I've tried multiple streaming profiles by changing Emby's user settings on Tvheadend. This particular case was using the default htsp stream setting, but the same result occurs when using a passthrough mpegts stream or an mkv stream.

 

Interestingly the command line is exactly the same. The only difference is that it's getting the stream from the tv head end server and not directly from the hdhr.

[Cam1878 0]

Interestingly the command line is exactly the same. The only difference is that it's getting the stream from the tv head end server and not directly from the hdhr.

 

Exactly, I'm not sure where to start on this one. I'm currently running Tvheadend on a Raspberry Pi 2 and I'm wondering if it might be a throughput issue. I'm setting it up on better hardware before trying anything else just to rule that out.

 

I don't expect that to be the issue, since it can stream to multiple Kodi sessions simultaneously without issue.

[Tolotos 61]

Hi,

which version of tvheadend are you using? The message at login to tvheadend is strange: 

2016-08-03 11:43:50.8188 Info App: [TVHclient] HTSConnectionAsync.authenticate: getDiskSpace don't deliver required field 'freediskspace' - htsp wrong implemented on tvheadend side.
2016-08-03 11:43:50.8188 Info App: [TVHclient] HTSConnectionAsync.authenticate: getDiskSpace don't deliver required field 'totaldiskspace' - htsp wrong implemented on tvheadend side.

The plugin catches the exception:

2016-08-03 12:48:31.8491 Error App: [TVHclient] SendingHandler caught exception : System.Net.Sockets.SocketException: The socket has been shut down
at System.Net.Sockets.Socket.Send (System.Byte[] buffer) <0x4061fb50 + 0x000bf> in <filename unknown>:0
at TVHeadEnd.HTSP.HTSConnectionAsync.SendingHandler () <0x4061b130 + 0x0008b> in <filename unknown>:0 
2016-08-03 12:48:31.8509 Error App: [TVHclient] HTSConnectionHandler recorded a HTSP error: The socket has been shut down
    *** Error Report ***
    Version: 3.0.6020.0
    Command line: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -ffmpeg /usr/bin/ffmpeg -ffprobe /usr/bin/ffprobe -restartpath /usr/lib/emby-server/restart.sh
    Operating system: Unix 4.1.17.6
    Processor count: 4
    64-Bit OS: True
    64-Bit Process: True
    Program data path: /var/lib/emby-server
    Mono: 4.2.1 (Stable 4.2.1.102/6dd2d0d Thu Dec 3 04:04:55 UTC 2015)
    Application Path: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe
    The socket has been shut down
    System.Net.Sockets.SocketException
     at System.Net.Sockets.Socket.Send (System.Byte[] buffer) <0x4061fb50 + 0x000bf> in <filename unknown>:0
     at TVHeadEnd.HTSP.HTSConnectionAsync.SendingHandler () <0x4061b130 + 0x0008b> in <filename unknown>:0

Than it tries to reconnect and sending a DataSourceChanged event to Emby:

DataSourceChanged(this, EventArgs.Empty);

@@Luke is this call correct?

 

After this the exception is thrown to Emby - maybe this is the error. 

I attached a verison with more logging and removed the throw to Emby. 

 

Please test with this version and post the logs.

 

-- Tolotos

 

 

 

 

TVHeadEnd.zip

[gstuartj 39]

.

Edited August 4, 2016 by gstuartj

[Luke 37071]

You would only call DataSourceChanged in order to indicate that something within tvheadend has happened that has caused the EPG to change, which will signal to Emby to refresh it. This will refresh the entire EPG so it's generally only used after a configuration change, like changing the location of the tvheadend server, or changing the channel lineup or something like that. You wouldn't called it after a failed playback attempt or after a recording.

[Tolotos 61]

How can I tell Emby to repeat the last command? 

[Luke 37071]

repeat what command?

[Tolotos 61]

The last call which results in the error state. 

Like a PleaseRepeatTheLastMethod call event.

That's why I trigger the DataSouceChanged event. 

 

If I think more about this I come to the result this may cause an endless loop.  

Logging the issue and not throwing to Emby would be the best solution. 

[Luke 37071]

you should throw the exception and avoid calling DataSourceChanged.

 

if you want to retry opening a channel stream then i would just use the sequence - try/catch -> try/catch -> throw

[Cam1878 0]

Hi,

which version of tvheadend are you using? The message at login to tvheadend is strange: 

2016-08-03 11:43:50.8188 Info App: [TVHclient] HTSConnectionAsync.authenticate: getDiskSpace don't deliver required field 'freediskspace' - htsp wrong implemented on tvheadend side.
2016-08-03 11:43:50.8188 Info App: [TVHclient] HTSConnectionAsync.authenticate: getDiskSpace don't deliver required field 'totaldiskspace' - htsp wrong implemented on tvheadend side.

The plugin catches the exception:

2016-08-03 12:48:31.8491 Error App: [TVHclient] SendingHandler caught exception : System.Net.Sockets.SocketException: The socket has been shut down
at System.Net.Sockets.Socket.Send (System.Byte[] buffer) <0x4061fb50 + 0x000bf> in <filename unknown>:0
at TVHeadEnd.HTSP.HTSConnectionAsync.SendingHandler () <0x4061b130 + 0x0008b> in <filename unknown>:0 
2016-08-03 12:48:31.8509 Error App: [TVHclient] HTSConnectionHandler recorded a HTSP error: The socket has been shut down
    *** Error Report ***
    Version: 3.0.6020.0
    Command line: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -ffmpeg /usr/bin/ffmpeg -ffprobe /usr/bin/ffprobe -restartpath /usr/lib/emby-server/restart.sh
    Operating system: Unix 4.1.17.6
    Processor count: 4
    64-Bit OS: True
    64-Bit Process: True
    Program data path: /var/lib/emby-server
    Mono: 4.2.1 (Stable 4.2.1.102/6dd2d0d Thu Dec 3 04:04:55 UTC 2015)
    Application Path: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe
    The socket has been shut down
    System.Net.Sockets.SocketException
     at System.Net.Sockets.Socket.Send (System.Byte[] buffer) <0x4061fb50 + 0x000bf> in <filename unknown>:0
     at TVHeadEnd.HTSP.HTSConnectionAsync.SendingHandler () <0x4061b130 + 0x0008b> in <filename unknown>:0

Than it tries to reconnect and sending a DataSourceChanged event to Emby:

DataSourceChanged(this, EventArgs.Empty);

@@Luke is this call correct?

 

After this the exception is thrown to Emby - maybe this is the error. 

I attached a verison with more logging and removed the throw to Emby. 

 

Please test with this version and post the logs.

 

-- Tolotos

 

I'm currently running the latest version compiled from source. There isn't a version of Tvheadend 4.1 for arm devices in the repo. Version 4.1-2141~g01c26fc

 

I ran your test plugin and it worked.

 

I set the guide to refresh every 15 minutes then restarted the server.

 

The first run happened at 17:23:43, the 2nd started at 17:38:43.

 

Both ran successfully. I've cut out all the guide data in the log as each run added about 500k lines of log.

 

Edit: I'm going to set the scheduler to run it every 3 hours like I had it before to see if it happens then.

 

Edit2: Three hours later it still works fine and loads the guide data without any socket error.

 

What exactly was changed in the test version?

Log.txt

Edited August 5, 2016 by Cam1878

[Cam1878 0]

On an unrelated topic, I've found another issue while using the Tvheadend client.

 

I use an HDHomeRun as my antenna receiver connected to Tvheadend.

 

The transcoding function is not working well at all when playing a channel via Tvheadend, but functions perfectly when I play it direct to Emby from the HDHomeRun.

 

Ideally I'd like Emby to use Tvheadend rather than directly from the HDHomeRun since I use Tvheadend with my Kodi clients; I want recordings all in one place.

 

Here is the transcode log when playing directly from the HDHomeRun -> Emby:

http://pastebin.com/raw/Bdbf8V4Z

 

Here is the log when playing the same channel from HDHomeRun -> Tvheadend -> Emby:

http://pastebin.com/raw/L3LyA476

 

Any suggestions on why the stream is becoming so broken when routed via Tvheadend?

 

I've tried multiple streaming profiles by changing Emby's user settings on Tvheadend. This particular case was using the default htsp stream setting, but the same result occurs when using a passthrough mpegts stream or an mkv stream.

 

I got Tvheadend up and running on the same server that Emby is hosted on and it is transcoding without issue.

 

At least it narrows the problem down. I assume it could either be a hardware capability issue of the RPi2, or possibly network related.

[IvanleFou 0]

Hi everyone,

 

First of all thanks Tolotos for your excellent work on this plugin and all the people that allow Emby to live and to evolve 

 

I noticed that when watching a TV channel Emby dashboard says that the stream is always transcoded at 8.2mbps whatever the original stream size is (I have streams from 4Mbps to 15Mbps). I was curious to know if it is a fixed choice from Emby or the plugin? Is it possible to modify that data rate? Transcoding to reduce the stream size I understand it but transcoding from 4Mbps to 8.2Mbps I do not get it. Is it even possible?

 

Thanks again for your work guys,

 

Ivan

[dcrdev 251]

Hi everyone,

 

First of all thanks Tolotos for your excellent work on this plugin and all the people that allow Emby to live and to evolve 

 

I noticed that when watching a TV channel Emby dashboard says that the stream is always transcoded at 8.2mbps whatever the original stream size is (I have streams from 4Mbps to 15Mbps). I was curious to know if it is a fixed choice from Emby or the plugin? Is it possible to modify that data rate? Transcoding to reduce the stream size I understand it but transcoding from 4Mbps to 8.2Mbps I do not get it. Is it even possible?

 

Thanks again for your work guys,

 

Ivan

 

This is something I've noticed as well the stream quality seems to be fixed no matter what quality you select.

 

Also on an unrelated note - seeking in recordings doesn't appear to work; is anyone else having the same problem?

Edited August 10, 2016 by dcrdev