When I place imports inside of the DVR folder, they no longer show in the library. I updated the path in the settings, but it they do not show. I rebooted the Pi with no luck. If I put them outside of DVR and just in media they show up instantly in the library.
On a newly setup 1016.2213 server, I navigated from /admin/settings to /welcome in order to restore passes I had copied from the existing server's HD into the new one's, but I was warned that I first had to disable the DVR before I could do the restore. I returned to /admin/settings, disabled Bonjour and the DVR, then returned to /welcome/restore and restored the metadata.
I went back to admin/settings and checked to find that the passes I wanted to have on the new server were there, but I forgot to re-enable Bonjour and the DVR.
I happened to have a local display attached the Pi4. The next time I rebooted the Pi, instead of seeing the server prompt for a root login as it normal does, the screen went black and the server wasn't accessible on the network. I watched it attempt to reboot in a loop that ran for at least 3 passes. I had to re-image to get it back.
Question: The newly imaged server came up, downloaded its guide, and began recording local and network news at 6PM EDT per the passes I restored into it, but the admin page (and logs) show its time zone as UTC. Why UTC?
My attention was called to that because I restarted the long running Raspian-based server and left it running. Its server correctly shows EDT, matching the Raspian system datetime.
What is the correct way to shut down and remove the drive for a user who is not knowledgeable with Linux commands.
While i wait for the slow transfer of recording files - just to avoid having to do this again...
Any harm in restoring the database while recording files are still awaiting transfer, aside from not being able to play them yet?
You can restore the database first and copy the files later.
I tried both a small and large drive on Windows and neither one's exFat partition is visible. Will have to try some variations to see if I can get Windows to pick it up.
Is there another place the imports can be placed since they are not picked up inside the media/DVR/Imports directory? Or is there a setting I am missing?
What is the Local Content section of the settings show? Is it configured to look under Imports?
Here is how it is setup. I cannot see anything under media/DVR/Imports/*, but I can see what is under /media/Movies. I did not have an Imports folder under DVR by default, so I created the one that is there.
Okay fix coming. Right now your log probably says "ignoring inside dvr folder" but that is fixed in the next build which you can update to in about 15min.
I also plan to create the Imports directories automatically but you've done it correctly manually.
I'm also going to be adding SMB access next week to make this all simpler.
1 Like
1bfc51fc-06e8-4a10-9673-122243750eac submitted.
Weird padding going on - a one hour recording seems to be going for 5. A few recordings i've done since finally importing my database share the same issue.
...wondering if the timezone on raspian pi (which was probably EDT), where my db was built, is misbehaving with the DVR server build (UTC)
ah - may be display bug only. Appears recordings are stopping on time, but the status display is showing them continuing until the UTC time.
I noticed that my imaged server is also on UTC after my Raspian-based server, which is on EDT, failed to record two 6PM Newscasts. I had taken it down briefly to copy one of its backups and later found it "idle" and those jobs "pending" while it should have been recording them. I had no problem sampling one of them live with the web client other than the usual transcoding stutter. The log contained no entries for those jobs, but it contained some timestamped entries for a clock time that hadn't happened yet. Refreshing the guide seemed to correct the log and it recorded SNL perfectly several hours later. I may have booted it a minute before I remembered to reconnect it to my network, but otherwise I have no explanation for why it acted up. I was careful not to write to its drive while it was down for copying.
The imaged server with its passes restored from the copy recorded both newscasts and SNL flawlessly despite being on UTC.
The latest update fixed it. Imports are now showing. Thanks!
1 Like
yeah i got worried, but my recordings have been fine. It's just the web UI confusing the UTC end time with local, from the looks of it.
Adding timezone selection is on my TODO list.
The latest images now properly mount in Windows:
I was also able to fix my existing imaged disk using the instructions here: https://askubuntu.com/a/1058425. Make sure you use gdisk 1.0.5 because 1.0.4 hosed my disk
FYI, I am seeing an issue where boot fails off my WD 12TB after a soft reboot. It only boots after pulling power.
I see some similar reports and indications that rpi eeprom flags that may help. We are set up to push eeprom updates via our OS updater if needed.
I experienced the same thing on a Seagate 6TB. Everything boots fine if I pull the HD power after shutdown.
1 Like
No issue on my end. Just did a soft boot for latest OS build too.
I am running 2020.10.18.0159. Is there a need to go thru the gdisk steps? If so, what's the benefit?
The benefit is being able to attach to Windows to directly transfer files. I don't recommend messing with gdisk unless you are comfortable with partitioning and have a backup.
1 Like