[timothee]

I just refreshed my memory how I did pull WiFi VID/PID list in Jan 2014: only versions 101/102/103R of str files giving the chance; using a hex editor, need to cut out ~65 bytes of a header the str file, up to a signature "hsqs"; then mount the file under Linux. After that you could copy all folders/files to your USB drive [FAT32] and dissect it under Windows.

That was helpful. since i have a raspberry Pi linux system... i downloaded 102R. you are correct... 135R layout is different and either zipped somehow or encrypted?

binwalk /home/pi/102r.str

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
65 0x41 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 31027255 bytes, 799 inodes,
blocksize: 131072 bytes, created: 1970-01-01 00:00:00
31097153 0x1DA8141 gzip compressed data, has original file name: "kernel.img", from Unix, last modified: 2014-01-17 11:21:50

extract the file system to a file
dd if=102r.str skip=65 count=31097088 of=102.fs

extract the kernel image and unzip
dd if=102r.str skip=31097153 of=kernel.gzip
binwalk -e kernel.gzip

create a place to mount the file system
sudo mkdir /media/102r

mount the file system as read only
sudo mount -o ro 102r.fs /media/102r

now the 102 file system can be browsed

ls /media/102r

hexedit kernel.img

 

[P Smith]

I'm glad to keep you busy

 

[markr68]

Just curious, has anyone ever tried plugging a standard USB keyboard into the USB port to see if it could be used to manipulate the UI? If it worked, it could possibly be a mechanism to "control" the DVR remotely.

 

[timothee]

I tried it just now. nothing really happens. until we can find the linux 'terminal' port, its going to be difficult to do anything 'fun'
There should be 3-4 pieces of software in dvr:

1) a 'bootloader' which is the first code to execute to setup the basic processor hardware (memory, registers, peripherals) and then it should start the basic OS, the linux kernel. There is usually a very basic console, typically 'rs-232' type access, but I cant find it after numerous attempts. dvr FW screen says this is V105S. Best I can figure dvr uses either the CFE bootloader (which broadcom seems to use for its router line), or maybe BOLT for its STB chips and I can find nothing on that at all.

2) the linux kernel. This was extracted from 102r.str with Mr. Smiths suggestions and you can get a copy here. you can use hexedit to view and search the file. The kernel img seems to include a ubi file system (something that can be mounted from flash) (see #3). The kernel should bring up linux and start the application. the kernel should also have a terminal port.

3) the dvr 'application' code. The basic file system can also be extracted from 102r.str and a zip file of that directory structure in also available. there is a dst_app, elg_atsc app and some other internesting things there like a file called 'run' which I will include below. common directories like /etc/xxx are not there, but might be in the kernel.img.
i dont know linux scripting well enough to understand the run script, but it does mention a gdbserver and the ip address 192.168.1.1:5678

DVR lists a Downloader version 104B, but im not sure if that is separate software or just the version of the downloader code embedded in the bootloader and/or in the kernel

#!/bin/sh
SCRIPT_NAME=$0
SCRIPT_DIR=$(cd $( dirname $0 ); pwd)
[[ ${SCRIPT_DIR} == /echostar ]] && running_from_flash=1 || running_from_flash=0

# Read in details of the DHCP connection
if [ -f /var/run/udhcpc.eth1.stat ]; then
   source /var/run/udhcpc.eth1.stat
elif [ -f /var/run/udhcpc.eth0.stat ]; then
   source /var/run/udhcpc.eth0.stat
fi

# create the trellis install symlink
ln -s ${SCRIPT_DIR}/AppLibs/usr/local /usr/local

# Prefix the current directory to the library search path
# Note: ECHOSTAR_LD_LIBRARY_PATH is used by beyond this script - do not delete!
export ECHOSTAR_LD_LIBRARY_PATH=$PWD:$PWD/lib:$PWD/lib/gstreamer-0.10:$LD_LIBRARY_PATH

export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib/trellis:${ECHOSTAR_LD_LIBRARY_PATH}

# Prefix the current directory, bin and sbin to the executable search path

export PATH=$PWD:$PWD/bin:$PWD/sbin:$PATH

# Add path for gstreamer library

export GST_PLUGIN_PATH=$PWD/lib/gstreamer-0.10

# Force GLIB to use malloc all the time, instead of memory slices

export G_SLICE=always-malloc

# Check that we are running as root (we might want to change this in future)

if [ "$(id -ru)" -ne "0" ]
then
   echo "You need to run as root."
   exit 1
fi

# Set number of message queues to 500

echo "500" > /proc/sys/kernel/msgmni

insmod lib/modules/wireless/8192cu.ko

# call the script to set the debug level,if the script is present

if [ -e debug_setting.sh ]
then
   source debug_setting.sh
else
   echo "debug_setting.sh" file does not exist
fi

# Initialise & parse options
show_help=0
store_scratch=0
mount_usb=0

# By default, we don't run with gdbserver
debugger=0
debugtrellis=0

# By default, the default app will be mounted and run from PREFIX_DIR
force_current_dir=0

# Process command line flags

while [ $# != 0 -a "${1:0:1}" = '-' ]
do
   case $1 in
      '-h' | '--help'  ) show_help=1 ;;
      '-d' ) debugger=1  ; echo "Running with gdbserver" ;;
'-dt' ) debugtrellis=1  ; echo "Running Trellis with gdbserver" ;;

      '-u' ) mount_usb=1 ; echo "USB will be mounted" ;;
      '-s' ) store_scratch=1 ; echo "Using scratchpad file for store" ;;
      *    ) echo >&2 "Error - invalid parameter '$1'!"; exit 1 ;;
   esac
   shift
done

if [ "${show_help}" = "1" ]
then
    echo "Usage: $0 [elg_atsc] [options]"
    echo "Options: -d           Invoke gdbserver"
echo "         -dt          Invoke gdbserver with Trellis build"

    echo "         -u           Mount USB drive explicitely (assumes driver already loaded)"
    echo "         -s           Allow NVM store to use a scratchpad file"
    echo "Example: $0 -d -u"
    exit 0
fi

if [ "${mount_usb}" = "1" ]
then
  # If present, USB device will be /dev/sda1
  USB_DEVICE_NODE=/dev/sda1

  i=0

  printf "\nWaiting for USB to start."
  (read <${USB_DEVICE_NODE}) 2>/dev/null

  # While there are errors try re-reading USB (5 seconds)
  while [ $i -lt 5 -a $? -ne 0 ]
  do
   let i++
   printf ".";
   sleep 1;
   (read <${USB_DEVICE_NODE}) 2>/dev/null;
  done

  # Mount if able to read USB
  if [ 0 -eq $? ]; then
   echo "Mounting USB (${USB_DEVICE_NODE})"
   mkdir -p /var/mnt/usb
   mount ${USB_DEVICE_NODE} /var/mnt/usb
  fi
fi

# Setup links to hdd mount points
#ln -s $PWD/mnt/av /mnt/av
#ln -s $PWD/mnt/hd /mnt/hd
#ln -s $PWD/mnt/browser /mnt/browser
#ln -s $PWD/mnt/misc /mnt/misc

# if file based nvm store is enabled, create and mount the store directory on /mnt/nvm_file_store

#ensure that the box will still be running if in case the hdd or any of the above fails

# default BASE_PATH the file based  nvm store on ubifs.
[ ! -d /mnt/flash/echostardata/store_nvm ] && mkdir -p /mnt/flash/echostardata/store_nvm
ln -s /mnt/flash/echostardata/store_nvm/ /mnt/nvm_file_store

#set store_scratch if enabled from build command line.

#if enabled BASE_PATH for scratch pad file is /mnt/store_temp
if [ "${store_scratch}" = "1" ] ; then
  mkdir -p /mnt/store_temp
  #if hd partition on HDD is mounted, use it.
  if [ "$(mount | grep /mnt/hd)" != "" ] ; then
    if [ "$(ls /mnt/hd/ | grep store)" != "" ] ; then
      mount  /mnt/hd/store /mnt/store_temp
    else
      mkdir -p /mnt/hd/store
      mount  /mnt/hd/store /mnt/store_temp
    fi
  # create & use  /var/store .
  # HDD is mounted by DVR_INIT, but after store init. Hence we would always be using /var
  else
    mkdir -p /var/store
    mount /var/store /mnt/store_temp
  fi
fi

# Create 4Mb of VUDU data storage on tmpfs
mkdir -p /var/appdata/vudu
mount -t tmpfs -o size=4m tmpfs /var/appdata/vudu

# Set the application name with a default

DEFAULT_APP_NAME=elg_atsc
appname=${1:-${DEFAULT_APP_NAME}}
shift

# if we are running the default app outside from nfs then
# mount to PREFIX_DIR and run from there.
if [[ $appname == ${DEFAULT_APP_NAME} && 0 == ${running_from_flash} ]]; then
  mount -o nolock,tcp,wsize=4096,rsize=4096 $serverid:/usr2/buildcache/view/build-gand_FLATATSC_102R_webbuild_Release_Label_Build_View/elg_atsc_flatatsc/release /echostar \
  && echo "SUCCESS: mount -o nolock,tcp,wsize=4096,rsize=4096 $serverid:/usr2/buildcache/view/build-gand_FLATATSC_102R_webbuild_Release_Label_Build_View/elg_atsc_flatatsc/release /echostar"\
  && appname=/echostar/$appname
fi

# Add gdbserver to the command name we will run
if [ "$debugger" = "1" ]
then
   appname="gdbserver 192.168.1.1:5678 $appname"
fi

# Add gdbserver to the Trellis BAM command. See AppLibs/broadcom/trellis/servers/start_trellis_echostar.sh
if [ "$debugtrellis" = "1" ]
then
  export DEBUG_TRELLIS_GDBSERVER="gdbserver 192.168.1.1:5678"
fi

# Disable DLNA at runtime on Trellis builds as elgist network changes causes BME to crash if DLNA enabled or NETAPP(disabled in build) running
export disable_dlna=y

# Run!
echo "RUNNING: $appname $@"

# Enable overcommit_memory - May not be the most suitable place to put this,
# but it gets us running for now
echo 0 > /proc/sys/vm/overcommit_memory

## TODO! still need to figure out best way to launch in debugger, since we don't directly launch the elgist process
cd /usr/local/bin/trellis
ECHOSTAR_TRELLIS_APP="$appname $@" ./start_trellis_echostar.sh

 

[JHBrandt]

Things have been pretty quiet on the PiGS front. I have V1.23 installed and it's been running with no evident problems for the last month.

Anyway, I decided to post a few logos/icons for some channels I get in DFW, and which some of you may also get, but which seem to be missing from my CM and SD icon sets. I figured some of you may be missing them also, so here they are. Just upload them to your myicons subdirectory and change the name to the correct channel for your area.

Cheddar and NewsNet are news channels. Timeless TV is a mix of infomercials and public-domain TV shows (a few old episodes of Bonanza, Beverly Hillbillies, and Petticoat Junction). MMN is similarly a mix of infomercials and public-domain movies.

 

[frank70]

Things have been pretty quiet on the PiGS front. I have V1.23 installed and it's been running with no evident problems for the last month.

Same here, V1.22 running 41+ days on a Pi Zero W, and having licked the lxpanel memory leak issue, very stable in memory usage (160 to 180 MB in use, the heavy hitters being the remote desktop X server and PiGS at around 60 MB each and the two lxpanels at 28 MB each). Not running V1.23 only because I didn't want to stop this one. No reason to believe it wouldn't run forever like this!

 

[timothee]

Same here, V1.22 running 41+ days on a Pi Zero W, and having licked the lxpanel memory leak issue, very stable in memory usage (160 to 180 MB in use, the heavy hitters being the remote desktop X server and PiGS at around 60 MB each and the two lxpanels at 28 MB each). Not running V1.23 only because I didn't want to stop this one. No reason to believe it wouldn't run forever like this!

My 1.23 is at 29 days. My Pi zero was running well but it went unresponsive because I inadvertently disconnected the VoNets bridge/access point I was using to monitor the Pi Zero with wireshark. I think it was running fine. Only some minor Schedule Search bug fixes and startup delays from 1.22 to 1.23

If someone is still running something before 1.23 (1.21 and before), PiGS might not run 'forever' because I was not using the request 'timeout' when making Schedules Direct API calls, which could lead to the Pi Hanging for no apparent reason. The simple code examples I was using early on did not use that parameter and I didn't catch it until 1.22/1.23 when I observed my Pi-Zero hanging 'for no reason'

r = requests.post(TokenPostURL, json={"username":username,"password":sha1pwd}, headers=newHeaders)

From the Requests docs, it says

You can tell Requests to stop waiting for a response after a given number of seconds with the timeout parameter. ​

Nearly all production code should use this parameter in nearly all requests. Failure to do so can cause your program to hang indefinitely: ​

After adding the timeout parameter, and improving the error handling (build retry every 20 minutes), the problem went away.

r = requests.post(TokenPostURL, json={"username":username,"password":sha1pwd}, headers=newHeaders, timeout=REQ_TIMEOUT)

@markr68 also encountered this issue running PiGS on his Synology NAS. Updating to 1.22/1.23 fixed it for him

It's a good idea to stay current. I've made no changes to PiGS since 1.23.

On another note, a while back I was able to get my Pi 4 to mount a usb drive which I then 'shared' with DVR+ (so the Pi4 is sitting between the External usb drive and DVR+). I am able to mount this drive on the Pi in read-only mode. DVR+ is able to record and playback through the Pi4. This is what @wlarsong did back in 2015. I haven't done anything more than that with it.

 

[JHBrandt]

I was able to get my Pi 4 to mount a usb drive which I then 'shared' with DVR+ (so the Pi4 is sitting between the External usb drive and DVR+). I am able to mount this drive on the Pi in read-only mode. DVR+ is able to record and playback through the Pi4. This is what @wlarsong did back in 2015.

I was pretty impressed with that trick at the time. It adds whole-home access to your DVR+ recordings.

The only thing is, the recording files have meaningless names (Strmxxxx.ts where xxxx is the index in hex into the REI file), so it's hard to know which file contains which recording. I always hoped he'd use some of @pachinko 's DVR+ Lister code to read both files and provide a more useful list of recordings, perhaps as an html page, but we never heard from @wlarsong again. Seems he left the forum; pity.

But if you have a Windows (or Linux with Wine) PC, seems you could access the drive as a network drive and run DVR+ Lister directly! Pick the recording you want, copy it to a directory for temporary files, watch with your favorite video player, then delete. In fact, DVR+ Lister even lets you specify a command to run on the recording file, which could be your video player!

 

[flowersrj]

Timothee,

If I understand your post correctly, you were able to share ONE usb drive between multiple DVR+s.

If so, can you provide detailed steps on how to do that?

Thanks,
Rich F

 

[timothee]

Timothee,
If I understand your post correctly, you were able to share ONE usb drive between multiple DVR+s.
If so, can you provide detailed steps on how to do that?

No that's not what I did. I plugged The DVR USB hard drive into my Pi4 and did some configuration so that the Pi4 exposed that drive on a different USB port and plugged the DVR into that. Using the command line I was able to mount the USB drive and then do a directory listing of the two partitions on the USB drive. That's it.

You can read wlarsong postings here on what he did and how he did it

Search results

www.avsforum.com

But basically he wrote some code to decipher the rei file and then copy off the TS files to another server where he I believe re-encoded the files so that they would stream over his network. He was using an external media server to serve his recordings out over his network.

 

[JHBrandt]

@wlarsong used a different SBC (a BeagleBone, not a Pi4). Most "lesser" Pis don't have the necessary hardware. According to Wikipedia, the Pis that will work are:

The RPi Zero, RPi1A, RPi3A+[71] and RPi4 can be used as a USB device or "USB gadget", plugged into another computer via a USB port on another machine.

Unfortunately we have to scratch the 1A and 3A+ from that list because they only have a single USB port, and this trick requires two. That leaves the Pi Zero and Pi 4.

I have a 3B+, so it looks like I'm out of this game unless I buy another Pi. But a Pi Zero will work, so it might be just the ticket for a very cheap PiGS/Whole Home setup for your DVR+, provided you already have a PC.

The only thing is, I'm not sure if the Pi Zero could run PiGS, pass USB data between the DVR+ and a drive, and serve the drive's files to, say, a PC running DVR+ Lister, all at the same time. Might need to schedule copying the recordings during some DVR+ "down time" to avoid overtaxing the thing.

A Pi4 might be able to handle it all even without the PC! Well, it couldn't run DVR+ Lister - Wine requires an Intel CPU - but perhaps the DVR+ Lister code could be ported to Python.

 

[timothee]

Unfortunately we have to scratch the 1A and 3A+ from that list because they only have a single USB port, and this trick requires two. That leaves the Pi Zero and Pi 4.
A Pi4 might be able to handle it all even without the PC! Well, it couldn't run DVR+ Lister - Wine requires an Intel CPU - but perhaps the DVR+ Lister code could be ported to Python.

The Pi zero only has 1 micro usb port... I dont think it will work. On the Pi4 the USB OTG is on the USB-C port, which is also the power port, so I had to supply 5V power via the expansion header (no biggie) so I could use a usb-C to usb-A adapter to connect to DVR+.

I'm no expert on streaming files (very much a novice), but I dont think the DVR+ TS files can be streamed directly. It sounds like they can be played by certain video players like VLC, but what we want is the ability to maybe use our Roku and other streaming devices to access the DVR content on our network (DLNA compatible). That requires the TS files be converted to a streaming format.

The Pi 4 could probably run a Plex (or other server) and stream converted files. We'd also need a place to store the converted TS files. A NAS could do that and the Pi4 could access that NAS over its gigabit ethernet. It might also be possible to connect a big multi-TB drive to the Pi4 using one of its other USB ports and have it serve the files directly.

From what I read, I dont think the Pi4 would have the HP to do the required video transcoding, which is why @wlarsong used an external computer to copy and transcode the files. He supplied his C-code to parse the REI file, which could be ported fairly easily. Basically he parsed the REI file and then created file links with nice names to the TS files so they could be accessed over the network and copied/converted. It would be nice if someone could do some tests with their existing hardware...

 

[P Smith]

transcode the files.

I don't see a necessity of transcoding, the files are pure TS [188 bytes], a direct copy from OTA transmitters; any modern player process the TS files.
To make the files easy to play, need add a couple packets with PAT+PMT info, I did explain the mod to @pachinko and posted here.

 

[JHBrandt]

The Pi zero only has 1 micro usb port... I don't think it will work.

Rats. Wikipedia misled me - it lists the Pi Zero as having one USB 2.0 port, and one USB OTG port, and the connector diagram shows two ports. But after I posted that, I started to wonder: what if the USB 2.0 port and USB OTG port were actually the same port, and the other "USB" port is just a power port, like on my 3B+?

Apparently that's the case. Oh, well. At least there are relatively inexpensive Pi 4's now; I guess that's the only Pi option for this trick.

To be sure, the Pi Zero is a pretty minimal Pi; it might not have had the horsepower needed in any case.

 

[JHBrandt]

I dont think the DVR+ TS files can be streamed directly. It sounds like they can be played by certain video players like VLC, but what we want is the ability to maybe use our Roku and other streaming devices to access the DVR content on our network (DLNA compatible).

Not long ago, I would've said Roku was a lost cause. MPEG-2 was patented, and Roku never sprang for the license. MPEG-4 is also patented, but they waived the license fee for streaming over the Internet, so Roku just built in a royalty-free MPEG-4 decoder and called it a day.

But I think the MPEG-2 patents have now expired and some of the newer Rokus now include MPEG-2 decoders. So those newer Rokus should work.

As @P Smith noted, the .ts files lack a couple of header packets, which causes problems for some players, but those can be easily added back (e.g., by piping through ffmpeg using the "copy" codecs; no transcoding required.) One reason DVR+ Lister included the option to run a command on the selected recordings, as an alternative to simply copying them, was for this purpose.

Making a Pi 4 into a DLNA-compatible media server is well beyond my expertise. But in theory I suppose it's possible.

 

[sam_adams]

Installing VLC on Rasberry Pi.

Using VLC as a streaming source—old how to.

Using VLC as a streaming source—new WIP how to.

For the brave—MiniDLNA for Pi.

 

[markr68]

Steps I used to install PiGS on a Synology NAS:

// Install Synology Python3 package
// Install pip3 on Synology using instructions from the Internet to be able to get the missing python modules later. This was a bit of a pain and I didn't write down all the steps.

// Follow PiGS1.1x setup instructions starting with step 4. NOTE: use the latest version of PiGS, not 1.1x.

// Stop Synology services that rely on the internal webserver like Web Station and Photo Station. I don't know if this is really necessary since I changed the default ports anyway.
// Change the Synology web server to non-default ports (81 and 444) so it does not conflict with PiGS.

sed -i -e 's/80/81/' -e 's/443/444/' /usr/syno/share/nginx/server.mustache
sed -i -e 's/80/81/' -e 's/443/444/' /usr/syno/share/nginx/DSM.mustache
sed -i -e 's/80/81/' -e 's/443/444/' /usr/syno/share/nginx/WWWService.mustache

// Synology Task command line running as root. I tried to run it as an admin user but it didn't work and I wasn't concerned enough to spend time trying to get it to work as a non-root user since the web server is not available on the Internet.
python3 /volume1/homes/YourUserAccount/PiGS_TV_Guide/pigs.py 80

// Restart Synology

// Configure PiGS as per setup instructions
// I turned off the DNS server because I already had Route 53 installed on Synology for another purpose. I added the 2 guide domains in Route 53 to redirect to PiGS on Synology.

 

[ColoradoCraig]

Pi Zero W wifi disconnecting after 3-4 hours. This is my solution that might help someone else.

I have PIGS running successfully on a Pi Zero W, running Raspberry Pi OS lite, configured for a static IP address, with the problem that the wifi connection failed within 3-4 hours of reboot.

In the logs I saw this message"dhcpcd[xxx]: wlan0: 10 second defence failed for 192.168.xxx.xxx" followed ultimately by, "systemd[1]: dhcpcd.service: Main process exited, code=killed, status=11/SEGV"

This turned out to likely be an interaction with my DSL modem/router due to a known issue with dhcpcd, and I resolved the issue by adding 'noarp' to a line in dhcpcd.conf and then, since dhcpcd was not automatically restarting, I also added the following in the /lib/systemd/system/dhcpcd.service to what was already in the '[Service]' block to restart the service on failure, I tested it and it works for me.

[Service]
Restart=on-failure
RestartSec=5s

 

[frank70]

Pi Zero W wifi disconnecting after 3-4 hours. This is my solution that might help someone else.

I have PIGS running successfully on a Pi Zero W, running Raspberry Pi OS lite, configured for a static IP address, with the problem that the wifi connection failed within 3-4 hours of reboot.

In the logs I saw this message"dhcpcd[xxx]: wlan0: 10 second defence failed for 192.168.xxx.xxx" followed ultimately by, "systemd[1]: dhcpcd.service: Main process exited, code=killed, status=11/SEGV"

This turned out to likely be an interaction with my DSL modem/router due to a known issue with dhcpcd, and I resolved the issue by adding 'noarp' to a line in dhcpcd.conf and then, since dhcpcd was not automatically restarting, I also added the following in the /lib/systemd/system/dhcpcd.service to what was already in the '[Service]' block to restart the service on failure, I tested it and it works for me.

[Service]
Restart=on-failure
RestartSec=5s

I'm a little confused by this. When you say you saw that message in a log, and changed some files, was that on your router that you did that? I ask because the Pi Zero W wouldn't be running a dhcpd AFAIK.

When you say "wifi connection failed within 3-4 hours of reboot", does that simply mean that a DVR+ or other computer on your network could no longer open a connection to the Pi's static IP address?

My Pi Zero W fails to respond to ARP request broadcasts after some amount of time (didn't narrow it down to a number of hours). I have a workaround implemented by running a background script on the Pi that periodically pings (or in the case of DVR+ units, attempts an ssh connection, which of course fails) each node on my network that needs to communicate with the Pi; that refreshes the ARP cache in each of these nodes and bypasses the need for ARP request response. If there is something you've done to the Pi Zero W's Raspbian OS to get around this, I'd be very interested. I have an ESP8266-based board that has virtually the same problem, but a Pi-2 and a Pi-3 that never have this problem.

 

[timothee]

I'm a little confused by this. When you say you saw that message in a log, and changed some files, was that on your router that you did that? I ask because the Pi Zero W wouldn't be running a dhcpd AFAIK.

looks like he's messing with dhcpCd, the client side of the dhcp process.

I did a "systemctl status dhcpcd" on my pi zero and there is a process running

I think there is something in the dhcp process that refreshes the dhcp lease when it is 50% expired or something like that???