Jump to content

VDR plugin development


Tuxx

Recommended Posts

blublub

Hi

 

From the posts in this thread it seems the VDR plug in for emby is dead in the water currently - or am I mistaken here?

Thx for some info

Link to comment
Share on other sites

Please try it out and report your experience. If the plugin source code is available, and if i can make a quick fix, then i don't mind helping to keep it compatible. Thanks !

Link to comment
Share on other sites

  • 3 months later...

I worked a bit a the last days on an updated version of the VDR plugin.

Attached version should work with latest emby 4.x version.

 

The restfulapi-plugin requires an updated verison of vdr-restfulapi, which is available here:

https://github.com/frank0304/vdr-plugin-restfulapi

 

VDR should be the latest version 2.4.0.

 

Updated emby plugin code you find here (branch: net_2.0_update)

https://github.com/frank0304/Emby.Plugins/tree/master/LiveTv.Vdr

 

In general most of the main features should work as before.

Single timer creation has been added, series timer does not work, yet.

 

Update on a single timer works one time, but requires then a reload of the web-page. Problem here is, that the timer_id of the vdr is changing with each update and therefore the timer must be reloaded via the interface again - need to figure out the easiest way to fix this.

 

 

 

LiveTv.Vdr.zip

  • Like 1
Link to comment
Share on other sites

domenic

it looks like the restfull spi code doesn't compile

 

Plugin restfulapi:

g++ -g -O3 -Wall -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/src/linux -I/usr/src/vdr-2.4.0/include -DUSE_LIBMAGICKPLUSPLUS -c -DPLUGIN_NAME_I18N='"restfulapi"' -I/usr/src/vdr-2.4.0/include -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/i386-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/i386-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/i386-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -o restfulapi.o restfulapi.cpp

In file included from epgsearch.h:18:0,

from events.h:12,

from serverthread.h:24,

from restfulapi.cpp:11:

epgsearch/services.h:160:12: error: ‘unique_ptr’ in namespace ‘std’ does not name a template type

std::unique_ptr<cServiceHandler> handler;

^

epgsearch/services.h:176:12: error: ‘unique_ptr’ in namespace ‘std’ does not name a template type

std::unique_ptr<cServiceHandler_v1_1> handler;

^

epgsearch/services.h:192:12: error: ‘unique_ptr’ in namespace ‘std’ does not name a template type

std::unique_ptr<cServiceHandler_v1_2> handler;

^

Makefile:76: recipe for target 'restfulapi.o' failed

make[1]: *** [restfulapi.o] Error 1

ls: cannot access /usr/src/vdr-2.4.0/PLUGINS/src/restfulapi/po/*.mo: No such file or directory

 

any ideas?

Link to comment
Share on other sites

domenic

here is the diff on the error

letourneau:/usr/src/vdr/PLUGINS/src/vdr-plugin-restfulapi.old/epgsearch# diff services.h ../../restfulapi/epgsearch/services.h

160c160

< std::auto_ptr<cServiceHandler> handler;

---

> std::unique_ptr<cServiceHandler> handler;

176c176

< std::auto_ptr<cServiceHandler_v1_1> handler;

---

> std::unique_ptr<cServiceHandler_v1_1> handler;

192c192

< std::auto_ptr<cServiceHandler_v1_2> handler;

---

> std::unique_ptr<cServiceHandler_v1_2> handler;

letourneau:/usr/src/vdr/PLUGINS/src/vdr-plugin-restfulapi.old/epgsearch#

Link to comment
Share on other sites

I worked a bit a the last days on an updated version of the VDR plugin.

Attached version should work with latest emby 4.x version.

 

The restfulapi-plugin requires an updated verison of vdr-restfulapi, which is available here:

https://github.com/frank0304/vdr-plugin-restfulapi

 

VDR should be the latest version 2.4.0.

 

Updated emby plugin code you find here (branch: net_2.0_update)

https://github.com/frank0304/Emby.Plugins/tree/master/LiveTv.Vdr

 

In general most of the main features should work as before.

Single timer creation has been added, series timer does not work, yet.

 

Update on a single timer works one time, but requires then a reload of the web-page. Problem here is, that the timer_id of the vdr is changing with each update and therefore the timer must be reloaded via the interface again - need to figure out the easiest way to fix this.

 

If we were to work this into our organization, going forward i can help with compatibility updates for Emby api changes.

Link to comment
Share on other sites

here is the diff on the error

letourneau:/usr/src/vdr/PLUGINS/src/vdr-plugin-restfulapi.old/epgsearch# diff services.h ../../restfulapi/epgsearch/services.h

160c160

< std::auto_ptr<cServiceHandler> handler;

---

> std::unique_ptr<cServiceHandler> handler;

176c176

< std::auto_ptr<cServiceHandler_v1_1> handler;

---

> std::unique_ptr<cServiceHandler_v1_1> handler;

192c192

< std::auto_ptr<cServiceHandler_v1_2> handler;

---

> std::unique_ptr<cServiceHandler_v1_2> handler;

letourneau:/usr/src/vdr/PLUGINS/src/vdr-plugin-restfulapi.old/epgsearch#

My fault, my compiler version highlighted a warning on the old ptr, must be changed to support old versions as well.

Link to comment
Share on other sites

domenic

One small request for a minor change to the handling of the live stream.  When I attempt to view a HD channel, I must stop and retry the stream.  In the past implimentation I used PES instead of the TS for the live stream URL.  I was wondering if you could externalize "TS" in the code below to a configuration option, that I could choose PES or EXT even if I prefered...

public async Task<MediaSourceInfo> GetChannelStream(string channelId, string streamId, CancellationToken cancellationToken)
        {
            _logger.Debug("[LiveTV.Vdr:GetChannelStream]  {0}...", nameof(GetChannelStream));
            var baseUri = Plugin.Instance.Configuration.VDR_HttpStream_BaseUrl;
            var streamUri = string.Format("{0}/TS/{1}", baseUri, channelId);

            _logger.Info("[LiveTV.Vdr:GetChannelStream] StreamUrl: {0}", streamUri);

            return LiveTvHelper.CreateMediaSourceInfo(channelId, streamUri);
        }
Link to comment
Share on other sites

If we were to work this into our organization, going forward i can help with compatibility updates for Emby api changes.

Totally agree on this, can you copy the source to your emby repository and release a beta version first? I'm trying to follow up on this the next few weeks, but I cannot promise anything.

 

It would be anyway a good idea, if you could review the code. For me it was the first time that I worked with C#.

Link to comment
Share on other sites

 

One small request for a minor change to the handling of the live stream.  When I attempt to view a HD channel, I must stop and retry the stream.  In the past implimentation I used PES instead of the TS for the live stream URL.  I was wondering if you could externalize "TS" in the code below to a configuration option, that I could choose PES or EXT even if I prefered...

public async Task<MediaSourceInfo> GetChannelStream(string channelId, string streamId, CancellationToken cancellationToken)
        {
            _logger.Debug("[LiveTV.Vdr:GetChannelStream]  {0}...", nameof(GetChannelStream));
            var baseUri = Plugin.Instance.Configuration.VDR_HttpStream_BaseUrl;
            var streamUri = string.Format("{0}/TS/{1}", baseUri, channelId);

            _logger.Info("[LiveTV.Vdr:GetChannelStream] StreamUrl: {0}", streamUri);

            return LiveTvHelper.CreateMediaSourceInfo(channelId, streamUri);
        }

 

I made just the experience that a HD stream needed a few seconds to run without any "delays" - was not aware that streamdev supports also other formats besides TS.... but, yes for sure - that is possible.

Link to comment
Share on other sites

domenic

Just a note from the Stream Docs...

3.1 Usage HTTP server:
----------------------

You can use the HTTP part by accessing the server with a HTTP-capable media
player (such as XINE, MPlayer, and so on, if you have appropriate MPEG2-codecs
installed). In the PlugIn's Setup, you can specify the port the server will
listen to with the parameter "HTTP Server Port". The parameter "HTTP Streamtype"
allows you to specify a default stream type, which is used if no specific type
has been requested in the URL (see below). The supported stream types are:

  TS     Transport Stream (i.e. a dump from the device)
  PES    Packetized Elemetary Stream (VDR's native recording format)
  ES     Elementary Stream (only Video, if available, otherwise only Audio)
  EXT    Pass stream through external script (e.g. for converting with mencoder)
Link to comment
Share on other sites

domenic

Don't bother updating the code to support other types (I did a quick compile of the code)... turns out that an HD stream will never be sent properly using PES format.... but for some reason the first view of an HD channel never shows any video, I must click the back arrorw and start the stream again for the picture to come in... It is not an issue with the code I don't believe, possibly a timing issue with the VDR streamdev software. 

 

Domenic

 

EDIT:  is it still possible to stop the interrogation of the live stream, that could be interfering with the startup?

Edited by domenic
Link to comment
Share on other sites

Totally agree on this, can you copy the source to your emby repository and release a beta version first? I'm trying to follow up on this the next few weeks, but I cannot promise anything.

 

It would be anyway a good idea, if you could review the code. For me it was the first time that I worked with C#.

Yes but I don't know anything about vdr, so I can only help from the emby side of things.

Link to comment
Share on other sites

frank84

Don't bother updating the code to support other types (I did a quick compile of the code)... turns out that an HD stream will never be sent properly using PES format.... but for some reason the first view of an HD channel never shows any video, I must click the back arrorw and start the stream again for the picture to come in... It is not an issue with the code I don't believe, possibly a timing issue with the VDR streamdev software. 

 

Domenic

 

EDIT:  is it still possible to stop the interrogation of the live stream, that could be interfering with the startup?

Do you have the same issues, if you use the IPTV-plugin from the catalogue?

Link to comment
Share on other sites

domenic

I actually have not tried any other channels, or are you suggesting placing a HD channel URL from VDR into this plugin?

Link to comment
Share on other sites

frank84

I actually have not tried any other channels, or are you suggesting placing a HD channel URL from VDR into this plugin?

Yes correct, I'm expecting to see same issues with the IPTV plugin - then it is most likely on the streamdev server side. Do you see anything inside the vdr log data?

Link to comment
Share on other sites

domenic

Hmmm I don't see the IP TV plugin from the catalog... 

 

EDIT:  NVM I found it

Edited by domenic
Link to comment
Share on other sites

domenic

I added a HD channel to the iptv plugin, but it did not play, what did you add as a channel to the plugin?

Link to comment
Share on other sites

frank84

OK - thank you.

Can you generate a debug log in emby with the vdr plugin? There might be some information missing about the stream content, that must be added to the plugin.

Link to comment
Share on other sites

domenic

OK - thank you.

Can you generate a debug log in emby with the vdr plugin? There might be some information missing about the stream content, that must be added to the plugin.

attached are 4 log files.  3 ffmpeg-transcode and the embyserver log file.  Note the first-try is a failure which will can be repeated by tuning a different HD channel.  the second-try is success when selecting the same channel again and the third is using the iptv plugin, which never seems to fail.   I suspect the probe of the channel before it is displayed fails (VDR tuning takes too long?) and does not create the proper stream, second time the channel has been tuned and the probe works properly.    And of course the server log file.

ffmpeg-transcode-hd-first-try.txt

ffmpeg-transcode-hd-second-try.txt

ffmpeg-transcode-hd-iptv-plugin.txt

embyserver-testhd.txt

Link to comment
Share on other sites

frank84

I had a look to the data, but I am not experienced enough to understand the issue.

For me it seems that ffmpeg is getting a stream with no video data inside:

video:0kB audio:758kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

Question is why? On my system I'm not seeing this. @@Luke ,can you support us on this?

 

 

The ffmpeg call of the three different trials are quite similar:

2019-03-07 18:49:12.848 Info App: ProcessRun 'StreamTranscode 5dda59' Execute: /opt/emby-server/bin/ffmpeg -i "http://127.0.0.1:23424/LiveTv/LiveStreamFiles/2fd7424f53354878a078592976faaf2c/stream.ts" -map_metadata -1 -map_chapters -1 -threads 8 -sn -c:v:0 libx264 -pix_fmt yuv420p  -maxrate 1308000 -bufsize 2616000 -preset slower -profile high -level 4.1 -crf 20 -x264opts:0 subme=0:me_range=4:rc_lookahead=10:me=dia:no_chroma_me:8x8dct=0:partitions=none -force_key_frames "expr:gte(t,n_forced*3)" -vf "yadif=0:-1:0,scale=trunc(min(max(iw\,ih*dar)\,720)/2)*2:trunc(ow/dar/2)*2" -vsync -1 -codec:a:0 ac3 -disposition:a:0 default -ac:a:0 6 -ab:a:0 192000  -f segment -max_delay 5000000 -avoid_negative_ts disabled -start_at_zero -segment_time 3  -individual_header_trailer 0 -segment_format mpegts -segment_list_entry_prefix "hls/a6870a6f9c2088d20c2e74ccdb174b23/" -segment_list_type m3u8 -segment_start_number 0 -segment_list "/var/lib/emby-server/transcoding-temp/a6870a6f9c2088d20c2e74ccdb174b23.m3u8" -y "/var/lib/emby-server/transcoding-temp/a6870a6f9c2088d20c2e74ccdb174b23%d.ts"

2019-03-07 18:50:57.127 Info App: ProcessRun 'StreamTranscode 33f561' Execute: /opt/emby-server/bin/ffmpeg -i "http://127.0.0.1:23424/LiveTv/LiveStreamFiles/3fde94bacfee4a8881565e402128c893/stream.ts" -map_metadata -1 -map_chapters -1 -threads 8 -sn -c:v:0 libx264 -pix_fmt yuv420p  -maxrate 1308000 -bufsize 2616000 -preset slower -profile high -level 4.1 -crf 20 -x264opts:0 subme=0:me_range=4:rc_lookahead=10:me=dia:no_chroma_me:8x8dct=0:partitions=none -force_key_frames "expr:gte(t,n_forced*3)" -vf "yadif=0:-1:0,scale=trunc(min(max(iw\,ih*dar)\,720)/2)*2:trunc(ow/dar/2)*2" -vsync -1 -codec:a:0 ac3 -disposition:a:0 default -ac:a:0 6 -ab:a:0 192000  -f segment -max_delay 5000000 -avoid_negative_ts disabled -start_at_zero -segment_time 3  -individual_header_trailer 0 -segment_format mpegts -segment_list_entry_prefix "hls/5beec636e036532950f1ce0b1dcbc048/" -segment_list_type m3u8 -segment_start_number 0 -segment_list "/var/lib/emby-server/transcoding-temp/5beec636e036532950f1ce0b1dcbc048.m3u8" -y "/var/lib/emby-server/transcoding-temp/5beec636e036532950f1ce0b1dcbc048%d.ts"

2019-03-07 18:53:10.989 Info App: ProcessRun 'StreamTranscode 087c88' Execute: /opt/emby-server/bin/ffmpeg -i "http://192.168.0.97:8555/S82.0W-257-107-1400" -map_metadata -1 -map_chapters -1 -threads 8 -sn -c:v:0 libx264 -pix_fmt yuv420p  -maxrate 1308000 -bufsize 2616000 -preset slower -profile high -level 4.1 -crf 20 -x264opts:0 subme=0:me_range=4:rc_lookahead=10:me=dia:no_chroma_me:8x8dct=0:partitions=none -force_key_frames "expr:gte(t,n_forced*3)" -vf "scale=trunc(min(max(iw\,ih*dar)\,720)/2)*2:trunc(ow/dar/2)*2" -vsync -1 -codec:a:0 ac3 -disposition:a:0 default -ac:a:0 6 -ab:a:0 192000  -f segment -max_delay 5000000 -avoid_negative_ts disabled -start_at_zero -segment_time 3  -individual_header_trailer 0 -segment_format mpegts -segment_list_entry_prefix "hls/584579038bd69d34bc7e54f38553c2e7/" -segment_list_type m3u8 -segment_start_number 0 -segment_list "/var/lib/emby-server/transcoding-temp/584579038bd69d34bc7e54f38553c2e7.m3u8" -y "/var/lib/emby-server/transcoding-temp/584579038bd69d34bc7e54f38553c2e7%d.ts"
Edited by frank84
Link to comment
Share on other sites

pünktchen

@@frank84 i would set SupportsProbing to true and remove the MediaStreams list from MediaSourceInfo inside your LiveTvHelper.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...