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!
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.
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.
If I format my existing drive and use the latest image, will the connection to Windows be available "out of the box"? If so, I can easily load my imports again, but will likely still use SSH after the first load to avoid having to unplug and move the drive each time I need to upload new files.
If you want to try and don't mind rebuilding, the following would be helpful:
gdisk -V says 1.0.5shutdown -r now then move the drive to a windows machine and check you can access the dvr driveIf that works I will make it automatic.
I am also adding SMB support which will be ready shortly.
Here is what I get when I run the first gdisk command from that site:
I also checked my directory and I do not have a folder or file called sdX inside the dev folder.
Use gdisk /dev/sda
EDIT: I decided to try it on an older install and when I rebooted my pi didn't come back. I will check it out more tomorrow but avoid this for now.
I've added support for samba access in the latest OS + DVR update.
I was able to connect and transfer a 6+GB file successfully using samba. At first, I received a message that there was not enough space on the drive. I rebooted the Pi and it worked successfully.
Thanks. I upgraded, then had no problem browsing to smb://dvr-server/media/DVR from a Mint 20 laptop, copying part of one of the mpg files, and viewing it there.
I tried to connect via SMB from my Windows 10 PC. Every time it just said there wasn’t enough space to copy anything. I rebooted the Pi multiple times with the same result.
Were you trying to copy into /media/DVR?
