Posts by ElwoodSC

    Hmm, no, it is not that obvious - I switched the player to standby yesterday at 23:06 and started it this morning at around 10:56. When started it was thinking it was 83 minutes earlier until after running for three minutes it synced NTP to the correct time (at 09:36:50 in the log).
    I guess if NTP sync would be in the resume from suspend stack than the problem would be gone. From my point of view I can't the a logic to when the ntp-client tries to sync time.

    When it is just running it seems to ntp every 17 minutes - that would explain the wait time after a resume from suspend.


    Code
    Jul 26 21:10:47.744371 mediawz connmand[506]: ntp: adjust (slew): +0.015361 sec
    Jul 26 21:27:51.744636 mediawz connmand[506]: ntp: adjust (slew): +0.008531 sec
    Jul 26 21:44:55.740670 mediawz connmand[506]: ntp: adjust (slew): +0.004358 sec
    Jul 26 22:01:59.716942 mediawz connmand[506]: ntp: adjust (slew): +0.001634 sec
    Jul 26 22:19:03.744245 mediawz connmand[506]: ntp: adjust (slew): +0.000759 sec
    Jul 26 22:36:07.676150 mediawz connmand[506]: ntp: adjust (slew): +0.000785 sec
    Jul 26 22:53:11.738523 mediawz connmand[506]: ntp: adjust (slew): -0.000112 sec

    Anyway, please try test image anyway. If nothing else, it should lower power consumption, since it disables Ethernet PHY in suspend.

    I installed your testbuild (maaaany thanks for your support btw.) yesterday and tested it - unfortunately it does not change the odd behaviour of not using the correct time after suspend. Here is a journalctl -o short-precise from just now, as you can see from the timestamps the system is hanging behind 83 minutes and it takes (in that case) 3 minutes to correct the time. On other occasions it took much longer - mostly I lost patience and just rebooted the system. On reboot I always have a correct time.


    ElwoodSC I prepared better test update, just follow links in previous post to test it.

    Thank you very much for that - I will test and report my findings! :)

    To elaborate a little more on the issue: To me it seems more like a Kodi issue than a OS issue, the player answers to PINGs as soon as it resumes from suspend but Kodi shows a not NTPed time on screen and is not able to access my PVR backend or my SMB-shares with movies.

    I found kodi-waitonnetwork: enabled by default with 10 sec timeout / use NTP for Online Status by mglae · Pull Request #4802 · LibreELEC/LibreELEC.tv · GitHub which comes quite close to my problems - but the fix is already included but does not work completely with my Tanix H6. Just to test it I disabled the WaitOnNetwork yesterday jut so see whether is does make a difference.

    Am I the only one having network problem with my Tanix H6 when returning from standby? The player is answering to pings but Kodi shows the wrong time and has no access to file shares or PRV backend.
    This happens mostly when the system was longer than 20-24h in standby and happens with these nightly builds as well as with the current audio passtrough testbuild.

    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!!! :)

    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?

    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. :/

    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

    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.

    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.

    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:[email protected]/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:[email protected]/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