Error after latest update

[Ranbato]

I downloaded the latest NPVR.zip file this morning since I saw that there was a new one.
Since then it always fails to record with the following error:
Have received 0 bytes from rtp source

There is an error on startup, but I don't know what might have changed to cause it.
Also, even after downloading and unzipping the latest zip, the UI still shows: Version: 5.0.0.190916  (5.0.0.191006 is available for download)

Attached logs.  I don't see anywhere it connecting to the actual IP of my tuners, but I don't have the old logs to compare to when it was working.  May have to revert to see what changed.

[mvallevand]

Since you didn't use the .deb installer you need to make sure your manual upgrade follows the correct steps (or maybe you meant to post in the docker forum based on the folder names you use?).

Martin

[Ranbato]

I posted here because I'm using a custom docker image to enable hardware encoding with ffmpeg so I suspect it is closer to Linux.  I could try the .deb, but I thought I read there are some issues with it in the current release.
I did find that I had the data dir incorrect, but even after correcting that I'm getting the same error.
For reference, here is how I'm setting up the image and another set of logs.

Code:

FROM jrottenberg/ffmpeg:4.1-vaapi AS base

#https://docs.microsoft.com/en-us/dotnet/core/linux-prerequisites?tabs=netcore22
#https://github.com/jrottenberg/ffmpeg/blob/master/azure-pipelines.yml


RUN apt-get update -y && \
    apt-get install -y --no-install-recommends unzip zip curl mediainfo libc6 libgdiplus hdhomerun-config kodi-pvr-hdhomerun liblttng-ust0 libcurl4 libssl1.0.0 libkrb5-3 zlib1g libicu60 && \
    rm -rf /var/lib/apt/lists/*


RUN curl https://dot.net/v1/dotnet-install.sh -O \
&& chmod +x ./dotnet-install.sh \
&& ./dotnet-install.sh -Channel 2.2 -Runtime dotnet -InstallDir /usr/share/dotnet \
&& ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet

RUN mkdir /app && cd /app
WORKDIR /app
RUN curl https://nextpvr.com/beta/linux/NPVR.zip -O
#COPY ./NPVR.zip /app/NPVR.zip
RUN unzip NPVR.zip


RUN find . -name DeviceHostLinux -exec chmod 755 {} \;


## cleanup


ENV  LD_LIBRARY_PATH=/usr/local/lib
ENV  ASPNETCORE_URLS=http://+:80
ENV  DOTNET_RUNNING_IN_CONTAINER=true
ENV  DOTNET_VERSION=2.2.7
ENV NEXTPVR_DATADIR=/app/data/
ENV NEXTPVR_DATADIR_USERDATA=/config/
ENV KODI_MEDIA=/kodi/

CMD         ["/app/NextPVRServer.dll"]
ENTRYPOINT  ["dotnet"]

I believe I have every prerequisite in the apt-get install line.

[sub]

With your legacy HDHomeRun, can you tell what frequency etc it's tuned to, and where it's sending the network data? ie, you might be able to see this in HDHomeRun Settings, or via the web app on the device or similar.

I'd check it's setting the frequencies, and setting the network target correctly. It looks like it is in the logs, but hard for me to know for sure.

[Ranbato]

I have figured out at least 1 problem: my HDHR devices were unplugged yesterday and so their IP addresses changed. Despite the correct IPs in the logs, NPVR was trying to record from the old IP addresses when streaming. Once I changed the values in the database to the new IP addresses, everything is working once more.

It is a bug that the IP addresses in the db aren't being updated at startup.

I'll go back through my troubleshooting and unwind it to see if there was anything else besides my initial directory goof up.

[sub]

I have figured out at least 1 problem: my HDHR devices were unplugged yesterday and so their IP addresses changed. Despite the correct IPs in the logs, NPVR was trying to record from the old IP addresses when streaming. Once I changed the values in the database to the new IP addresses, everything is working once more.

It is a bug that the IP addresses in the db aren't being updated at startup.

I've added logic to do this for the next build.

[mvallevand]

It's too bad this logic has to be at startup. In a v4 post I mentioned that I leave my HDHR's unplugged often enough that I can miss recording if I forget to restart the server. The same issue could come up if the IP changes in the lifetime of the server.

Martin

[sub]

Now you’re just being greedy

[Ranbato]

I guess the IP discovery method could run just before a recording starts. If there are long timeouts involved, maybe schedule it x minutes before the next recording.

[mvallevand]

For my case there is a bug in the rescan (at least in previous v5 versions) that I identified to sub. My device gets marked as disabled and the rescan enables it but I need to no d restart to get it back.

Martin