pvr.mediaportal - working in LE 9.26, not working in LE 10.0

1st Official Post

    Hi everyone,

    sorry to use my first post here for a problem report - but in the meantime I've quite exhausted my ressources.
    I'm running a Mediaportal 1 based installation with 4 DVB-S cards wich runs quite flawlessly for the families need of linear tv.
    I had two RPI3 with OSMC running in the past until I switched to LE and absolutely like the slimness of this distro. As more and more of my content comes in h.265 I reached out to a RPI4 to renew my TV-infrastructure - and here the quest began... ;)

    To use my RPi4 I needed to go to Kodi 19/LE 9.80 nightlies which worked with my MP-Server until around mid of january. Since then somehow access to the SMB-share which hosts Mediaportals timeshift-file is not working anymore. Currently I use prv.mediaportal version 8.1.0.3 and TVServerKodi 1.22.0.142.

    This is how it lookes on LE 10.0 (currently on Allwinner H6, same happens on RPI4):

    Code
    2021-04-06 13:25:50.182 T:957      INFO <general>: VideoPlayer::OpenFile: pvr://channels/tv/Alle%20Kan%c3%a4le/pvr.mediaportal.tvserver_3080.pvr
2021-04-06 13:25:50.183 T:1442     INFO <general>: Creating InputStream
2021-04-06 13:25:50.184 T:1442     INFO <general>: AddOnLog: pvr.mediaportal.tvserver: Open Live stream for channel uid=3080
2021-04-06 13:25:51.686 T:1442     INFO <general>: AddOnLog: pvr.mediaportal.tvserver: Channel timeshift buffer: D:\Video\Timeshift\live5-0.ts.tsbuffer
2021-04-06 13:25:51.687 T:1442     INFO <general>: AddOnLog: pvr.mediaportal.tvserver: Creating a new TsReader...
2021-04-06 13:25:51.687 T:1442     INFO <general>: AddOnLog: pvr.mediaportal.tvserver: TsReader open 'D:\Video\Timeshift\live5-0.ts.tsbuffer'
2021-04-06 13:25:51.688 T:1442     INFO <general>: AddOnLog: pvr.mediaportal.tvserver: Translate path D:\Video\Timeshift\live5-0.ts.tsbuffer -> smb://MY-Username:My-Password@NCC/mp-ts/live5-0.ts.tsbuffer
2021-04-06 13:25:51.688 T:1442     INFO <general>: AddOnLog: pvr.mediaportal.tvserver: FileReader::OpenFile() smb://MY-Username:MY-Password@NCC/mp-ts/live5-0.ts.tsbuffer.
2021-04-06 13:25:56.734 T:1442     INFO <general>: SMBFile->Open: Unable to open file : 'smb://USERNAME:[email protected]/mp-ts/live5-0.ts.tsbuffer'
                                                   unix_err:'6e' error : 'Connection timed out'

    And this ist how it should look (LE 9.2.6 on an RPI3):

    As you can see the logs are from the same timeframe, in case of the LE 10.0-Client the DNS-resolution for my server (NCC) fails, the used IP-Adress (172.20.108.1) is not even in my IP-network.
    As access to my movies and series lieying on a Windows server ist working in both LE versions I suspect the mediaportal-addon to be responsible here.

    Any ideas to ease my pain?

    Many thanks in advance,

    Cheers,

    Flo

    • Official Post
    Quote from ElwoodSC

    INFO <general>: SMBFile->Open: Unable to open file : 'smb://USERNAME:[email protected]/mp-ts/live5-0.ts.tsbuffer'

    I have no idea about mp1 but this looks like a problem of pvr.mediaportal.

    The ip 172... is a local subnet.

    Can you try Kodi + pvr.mp at some Windows10 PC?

    Otherwise I can imagine that this is some problem due the samba version change. Pls make sure your Winserver supports Samba2 and 3.

    I am just fishing for ideas :)

    On Windows 10 pvr.mp works as expected - version here is 8.1.0, the version in the LE-repository is 8.1.0.3.

    I was suspecting samba as well but SMC access to my fileserver (WinSrv 2016) works as it ever did. Additionally, when I tried to change pvr.mp to use RTSP instead of SMB i recognized that it also tries to access the RTSP-stream on 172...
    I still have a nightlie-build from 12/31/2020 which was working before - I tried that yesterday as well but was unable to install prv.mp because the repository is not available anymore.

    MS-Discovery is not available for Linux and SMB1 is disabled. Zeroconf/avahi MDNS seem to be more "agressive" in recent versions and resolving names directly.

    Your smb://MY-Username:MY-Password@NCC address is resolved to smb://USERNAME:[email protected] - maybe matching a virtual machine on your Windows system.

    Likely you get the same address with getent ahosts NCC in LE.

    Use the IP address instead of the name.

    Quote from mglae

    Likely you get the same address with getent ahosts NCC in LE.

    Use the IP address instead of the name.

    Code
    mediawz:~ # getent ahosts NCC
10.1.1.3        STREAM NCC.space.flo
10.1.1.3        DGRAM
10.1.1.3        RAW

    This IP-address is correct - I dont and have never used a 172.x-network.

    Actually I already use the IP-address of my server in pvr.mediaportal - but tha addon requests the target for the timeshift file from the Mediaportal Server addon (TVServerKodi) and I can't change it there to use an IP-address instead.

    CvH Possible. But 172.20.208.1 can't be random and i.e. WSL2 is using it automatically.

    ElwoodSC Please post the output of avahi-browse -a -r -t

    A possible work around may be adding your host NCC to the hosts file /storage/.config/hosts.conf.

    Please keep in mind that pvr.mediportal is still working flawlessly in my environment on LE 9.26 which runs on my daily driver in the livingroom on a x86 Intel NUC, I only have problems with LE 10 (or, currently 9.95 on my Allwinner H6-Box).

    Unfortunately the hosts-flie did not help - DNS-resolution on OS-Base does work for hostname and FQDN.

    Code
    mediawz:~ # nslookup NCC
Server:    10.1.1.102
Address 1: 10.1.1.102 vm-flovdc.space.flo

Name:      NCC
Address 1: 10.1.1.3 NCC

    So here is the output of avahi-browse:

    I cant pinpoint exactly until when pvr.mediaportal was running in a 9.80 environment but I am quite sure, that the problems begun around first or second week of january this year. At that time I had LE 9.80 running on a PRI4 and was fiddling around with deinterlacing of my TV programmes, so definately PVR was running at that time.

    Many thanks for your ideas, the are very much appreciated!!!

    Cheers, Flo

    Here is another log from LE 9.95 (Allwinner H6) when pvr.mediaportal is configured to use RTSP instead of SMB:

    Again it resolves to 172.20.208.1 instead of 10.1.1.3.
    I'm 99% sure that I tried RTSP on my RPI4 a couple of days before and that it was working there. :/

    Quote from CvH

    can you check with those 4 addons, and pls restart after installing ? just to rule out build related issues

    Index of /test/mp/

    btw thats all addons for Rpi4 - the naming is just for me :)

    I tested all your addons - unfortunately none of them worked, they all show the same problem. Should I take some logs for you?

    There is another report resolving a wrong address from SMB share (without mediaportal): SMB broken in nightlies RPI4

    Samba is doing it's own name resolution and in the last post OP found the address listed in nmblookup. Please try nmblookup NCC and nmblookup -A 172.20.208.1.

    BTW: nslookup is only querying DNS servers while the system library name resolution is using the methods defined in /etc/nsswitch.conf. For hosts these are usually files (->/etc/hosts). MDNS and DNS. This can be queries with the getent ahosts ... command mentioned.

    Quote from ElwoodSC

    Here is another log from LE 9.95 (Allwinner H6) when pvr.mediaportal is configured to use RTSP instead of SMB:

    RTSP failing too makes the error even more mysterious to me - maybe caused by caching of addresses.

    Comparing LE 9.2.6 with 9.95 does not help, almost every part was upgraded.

    Quote from mglae

    There is another report resolving a wrong address from SMB share (without mediaportal): SMB broken in nightlies RPI4

    I have seen this thread as well - but a least there is no pvr-addon involved.

    But you are on to someting:

    Code
    rpi-mediawozi:~/.kodi/temp # nmblookup NCC
10.1.1.3 NCC<00>
172.20.208.1 NCC<00>
rpi-mediawozi:~/.kodi/temp # nmblookup -A 172.20.208.1
Looking up status of 172.20.208.1
No reply from 172.20.208.1

    Edit: I just tried nmblookup on different machines in my network and all of them show the same name resolution. So obviously the faulty IP-address comes from my environment. But obviosly the different versions of pvr.mediaporal handle these addresses differently. Is there some kind of metric involved?

    Edited once, last by ElwoodSC (April 8, 2021 at 3:58 PM).

    Guys, I found the problem - thank you all for the tipps in this thread which led my, step by step, to the solution.
    I installed Docker on my Windows Server wich also runs my Mediaportal TVServer. Docker installed a Virtual NIC which is set to DHCP and - tadaaa - somehow gets the 172.20.208.1 address. Finally ipconfig /all on my server brought me to this:

    And when I disabled this adapter prv.mediaportal works like a charm!!!

    Sorry to have wasted your time - maybe this thread can help in the future when someon else encounters a similar problem.

    The strange thing which remains is still: why does LE 9.26 work in this environment...

    Thank you all for your help!!! :)

    Quote from mglae

    To my surprise Kodi is preferring nmblookup addresses over NSS and using the last listed line.

    Is there a difference in nmblookup output (because of older version)?

    Actually not:

    Code
    LibreELEC (official): 9.2.6 (Generic.x86_64)
nuc-mediawz:~ # nmblookup ncc
10.1.1.3 ncc<00>
172.20.208.1 ncc<00>

    So Kodi or the pvr-addon seem to handle name resolution differently...