AVS Forum banner

21 - 40 of 539 Posts

·
Registered
Joined
·
12 Posts
Anyone working on a WIN 10 solution? Seems like someone has it running in a Linux distro?



If we get python running under windows 10 do we do away with the need for the raspberry PI hardware?

timothee and I are currently testing an open-source Windows DNS Server that would take the place of dnsmasq on the Raspberry Pi. It was one of the relative unknowns before trying to see if PiGS would run in Python for Windows. It seems like a promising and easy to install/configure solution. I think he may be looking into integrating the same solution directly into Python for Windows. I also believe he is looking further into PiGS on Python for Windows. I'll let him answer to that.

If all of the above comes to fruition, then there would be no "need" for the Raspberry Pi hardware. Again, timothee can speak to that once he has gained more data.

I'm sure at some point he will integrate the instructions I have constructed into his Google Spreadsheet once we have more testing and a better idea if PiGS will be happy running in Python for Windows.

Mark
 

·
Registered
Joined
·
433 Posts
Auto Starting PiGS on Raspbian/Linux

For Pi/Linux users, consider using systemd to start PiGS. It's built in to Raspbian/Linux so there's nothing extra to install. Just create a unit that includes a 'REQUIRES=' statement for the network—or any other service—to be up before starting PiGS. With that in place, you won't have to login to the Pi and start PiGS if you have to reboot the device or it restarts after a power failure as PiGS will start almost like a service.

Some resources to get a handle on systemd:

https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files

https://man7.org/linux/man-pages/man1/systemd.1.html

https://www.man7.org/linux/man-pages/man5/systemd.unit.5.html

https://www.freedesktop.org/software/systemd/man/systemd.html

https://www.freedesktop.org/software/systemd/man/systemd.service.html
 

·
Registered
Joined
·
433 Posts
timothee and I are currently testing an open-source Windows DNS Server that would take the place of dnsmasq on the Raspberry Pi. It was one of the relative unknowns before trying to see if PiGS would run in Python for Windows. It seems like a promising and easy to install/configure solution. I think he may be looking into integrating the same solution directly into Python for Windows. I also believe he is looking further into PiGS on Python for Windows. I'll let him answer to that.

If all of the above comes to fruition, then there would be no "need" for the Raspberry Pi hardware. Again, timothee can speak to that once he has gained more data.

I'm sure at some point he will integrate the instructions I have constructed into his Google Spreadsheet once we have more testing and a better idea if PiGS will be happy running in Python for Windows.
As I mentioned over here, BIND is the DNS server that runs the Internet. It is available for Windows (and other platforms) and is open source. It is relatively easy to configure as all the config files are text based with a common syntax. The BIND ARM (Administrators Reference Manual) covers everything you need to now to run a DNS server on your local network.

If you want a GUI-based DHCP/DNS server for WIndows that is easy to configure, take a look Tftpd64. It's open source and there is an installer that allows it to run as a service so it would be available after boot without a login. (Ignore the security warnings that Chrome/Brave/Firefox may throw when visiting the site, there's nothing wrong there.)

If you need a lightweight httpd server for Windows there is MiniWeb. Open source and fairly easy to configure. Support is brutally lacking but it is very simple to config and get running.
 

·
Registered
Joined
·
2,163 Posts
FitMark and Sam_Adams,


Thanks for the work, updates and Info! It sounds like there potentially may be a Win10 solution that would be so great to have! Please keep us in the loop ( I know Timothee or someone will). Seems like progress is being made at a very rapid pace!
 

·
Registered
Joined
·
182 Posts
Discussion Starter #25
Auto Starting PiGS on Raspbian/Linux

For Pi/Linux users, consider using systemd to start PiGS. It's built in to Raspbian/Linux so there's nothing extra to install. Just create a unit that includes a 'REQUIRES=' statement for the network—or any other service—to be up before starting PiGS. With that in place, you won't have to login to the Pi and start PiGS if you have to reboot the device or it restarts after a power failure as PiGS will start almost like a service.

Some resources to get a handle on systemd:
Thanks for the links - I think I hit on some of those references... even after adding things like
After=multi-user.target
After=network-online.target
Wants=network-online.target​
PiGS was still crashing on boot, even though it seemed like it should do what you said.

Some references indicated there are different meanings of 'the network is ready'
bottom line, when systemd started pigs the network was not in a state pigs could use and it would crash.
so I tried some polling and found the network did become available after a bit... here is the PiGS startup log i get in v0.99:
INFO:root:MAIN: Current Working Directory /home/pi
INFO:root: Waiting for network 30
INFO:root: Waiting for network 29
INFO:root: Waiting for network 28
INFO:root: Waiting for network 27
INFO:root: Waiting for network 26
INFO:root:MAIN: PiGS IP = 192.168.1.200​
 

·
Registered
Joined
·
92 Posts
If all of the above comes to fruition, then there would be no "need" for the Raspberry Pi hardware.
Except for those you who already have a PI. I rather leave my PI on 24 hours a day than a Windows PC/laptop. Plus I have MOTION (for a camera) and PLEX (for music) running so no increase in electrical usage.



flowersrj
 

·
Registered
Joined
·
1,680 Posts
Except for those you who already have a PI. I rather leave my PI on 24 hours a day than a Windows PC/laptop. Plus I have MOTION (for a camera) and PLEX (for music) running so no increase in electrical usage.
Note that regardless of whether you have PiGS implemented on a Windows PC or a Pi, if you never use the internet apps (YouTube, Pandora, etc.) on the DVR+, then the Guide Server (whether it be PC or Pi) only needs to be powered up for maybe a half hour a day, and what half hour it is wouldn't seem to matter because apparently the DVR+ is persistent in its attempt to download a guide daily. For a Pi implementation with dnsmasq+PiGS autostart, what this means (in theory... I haven't actually tried this) is that you could put the Pi power supply on a timer and only turn it on for about a half hour each day.

Not that I want to do this (though I may try it with my Pi today), but for a power-hungry Windows machine if you boot it up autostarting DNS+PiGS at least once every day and leave it up long enough for a guide download to each DVR+ on your network, there would be no reason to leave it on 24/7.

If you do use the internet apps on the DVR+, you would need the DNS server up 24/7, or at least during the times you'd normally use those apps.

N.B.: re ...though I may try it with my Pi today...
It should be a good test of PiGS' ability to handle interspersed guide requests from two DVR+ units. I'll wait until about 6PM this evening after both units would have first tried to do today's guide updates.
 

·
Registered
Joined
·
12 Posts
As I mentioned , BIND is the DNS server that runs the Internet. It is available for Windows (and other platforms) and is open source. It is relatively easy to configure as all the config files are text based with a common syntax. The covers everything you need to now to run a DNS server on your local network.

If you want a GUI-based DHCP/DNS server for WIndows that is easy to configure, take a look . It's open source and there is an installer that allows it to run as a service so it would be available after boot without a login. (Ignore the security warnings that Chrome/Brave/Firefox may throw when visiting the site, there's nothing wrong there.)

If you need a lightweight httpd server for Windows there is . Open source and fairly easy to configure. Support is brutally lacking but it is very simple to config and get running.
Yeah, I looked at the BIND DNS, but was really looking for REALLY easy, as another part of the equation involves individuals that may not be as technically inclined as some of us that are already using a Pi for testing. I stumbled upon Technitium DNS Server and got it going by following the first 3 steps in their Getting Started section. I was then able to complete the task (very few steps) by using knowledge I already had about DNS in general.

Furthermore, I think I may have come up with another, possibly better solution for Windows involving VirtualBox (open-source) and Raspberry Pi Desktop ISO. It is pretty straight-forward for those with a bit of technical knowledge and if we can confirm it works just as well, everyone can have a Raspberry Pi experience without the expense of the Raspberry Pi hardware. It allows you to build a Virtual Appliance that you can then Export and share with other users that will require minimal configuration on their PC/network after importing it.

I have already created a virtual machine and tested (functionality) it on the same network as my physical Pi. I also imported that same virtual appliance into VirtualBox that I installed on my laptop and tested there, too. I think at this point it is just more testing, more testing, more testing. This could also be a "boot it once a day" option.

One of my Virtual Pi is currently my active PiGS and I will continue that way just to test.

I have also shared this with timothee for him to look at and test.

Mark

P.S. Had to remove your links, sam_adams, due to my post count being too low.
 

·
Registered
Joined
·
12 Posts
Except for those you who already have a PI. I rather leave my PI on 24 hours a day than a Windows PC/laptop. Plus I have MOTION (for a camera) and PLEX (for music) running so no increase in electrical usage.



flowersrj
There may be other "needs" for having the hardware, but I was speaking about those that are looking for a solution without purchasing extra hardware. I bought a Pi just because I was looking for an excuse to "play" with one. It is pretty cool having a desktop computer about the same size as a desktop mouse.

Mark
 

·
Registered
Joined
·
6 Posts
For those who don’t want to purchase a Pi device, you could utilize an old PC by installing MX Linux 19.2. I recommend MX Linux because it is one of the few Linux distros that doesn't bind systemd to port 53 (DNS) which would create a conflict with dnsmasq.

PiGS can be set to autostart by adding the following line to the end of the etc/init.d/rc.local file:

python3 /path to pigs directory/pigs.py 80

I have tested PiGS on an old laptop with MX Linux and it worked fine.
 

·
Registered
Joined
·
1,680 Posts
Possible PiGS bug (version 0.97)

This is information primarily for timothee. I think I discovered a bug in PiGS version 0.97. This may have been fixed in later version(s), but I haven't updated my Pi3 and haven't seen you mention this kind of bug before.

I had powered down my Pi3 early this afternoon. Then at ~6:11PM eastern, after both of my DVR+ units would have normally requested a guide update, I powered it back up and connected my remote desktop. I was expecting both DVR+ units to be chomping at the bit for a guide update, and was not disappointed. They both immediately started up requesting the guide update, with the requests relatively interspersed. Everything seemed to be progressing OK except some of the requests were showing the message:
LS:GLS:Request time before current ListIndex(2157). Restarting at 0...
But everything seemed to be progressing normally until the download for date/time:
2020-07-04T00:00:00Z
at which time the downloads for the second unit terminated, while the downloads for the first unit continued until:
2020-07-09T00:00:00Z

The pigs.log file did not show why, but the messages I captured from PiGS' stdout/stderr showed a number of error messages just before the last update on the second unit.

I've captured both pigs.log and the captured stdout+stderr output from PiGS and attached them here for your analysis. Also, after ignoring the strings "INFO:root:" and "WARNING:root:" in the pigs.log file, I made and attached a 3rd file that shows the diffs between the pigs.log and stdout+stderr files. Notice that the stdout+stderr file contains the error messages in the middle of the file, and an extra guide request entry from the second unit at the end of the file, neither of these being in pigs.log.

Hopefully, you can decipher this, but it clearly has something to do with concurrent guide requests arriving from two different DVR+ units. It seemed to be doing so good, and then... suddenly it broke! When I look at the guides in the two DVR+ units, the first unit has 14 days of guide, while the second unit has 13 days of guide (probably the old guide data, but I can't tell because it's probably unchanged anyway).

Hope I haven't ruined your day :frown:

UPDATE: Curiously, when I look at "Last Internet Guide Update" on both DVR+ units, they are very similar. The first unit (194) says:
Thu, Jun 25 - 06:22pm 2020 [403]
while the second unit (189) says:
Thu, Jun 25 - 06:24pm 2020 [403]
So I guess it's possible that the second unit's guide has new data out to July 4th, then old (yesterday's) data through July 7th. Again, there is really no way to tell; I don't know what the DVR+ does if it only gets a partial guide update.
 

Attachments

·
Registered
Joined
·
433 Posts
...UPDATE: Curiously, when I look at "Last Internet Guide Update" on both DVR+ units, they are very similar. The first unit (194) says:
Thu, Jan 25 - 05:22pm 2020 [403]
while the second unit (189) says:
Thu, Jan 25 - 06:24pm 2020 [403]...
I'll assume that the 'Jan' is a typo, but it looks like the time is off on 194—or that's a typo. Check the settings on the DVR+. Also, check your Pi to see if it is syncing to a working and reachable NTP server. It should be.

Pool of accessible NTP servers:

https://www.ntppool.org/en/

or list of Stratum Two Time Servers:

http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers

@timothee:

You might want to run some packet traces on the DVR+ to see if it is querying a time server to set the time on the device. Accommodations would have to be made to allow the device to get the proper time from the server it's querying.
 

·
Registered
Joined
·
433 Posts
... here is the PiGS startup log i get in v0.99:
INFO:root:MAIN: Current Working Directory /home/pi
INFO:root: Waiting for network 30
INFO:root: Waiting for network 29
INFO:root: Waiting for network 28
INFO:root: Waiting for network 27
INFO:root: Waiting for network 26
INFO:root:MAIN: PiGS IP = 192.168.1.200​
You might want to bump up the verbosity on the logging to see if you can track down the issue. Drop it back when solved.
 

·
Registered
Joined
·
1,680 Posts
I'll assume that the 'Jan' is a typo, but it looks like the time is off on 194—or that's a typo. Check the settings on the DVR+. Also, check your Pi to see if it is syncing to a working and reachable NTP server. It should be.
Sorry, all typos. I fixed them above. The gist is that both DVR+ units think they got a full guide update, but clearly the second unit never finished all the days.
 

·
Registered
Joined
·
182 Posts
Discussion Starter #35 (Edited)
This is information primarily for timothee. I think I discovered a bug in PiGS version 0.97. This may have been fixed in later version(s), but I haven't updated my Pi3 and haven't seen you mention this kind of bug before.

Hope I haven't ruined your day :frown:

UPDATE: Curiously, when I look at "Last Internet Guide Update" on both DVR+ units, they are very similar. The first unit (194) says:
Thu, Jun 25 - 06:22pm 2020 [403]
while the second unit (189) says:
Thu, Jun 25 - 06:24pm 2020 [403]
So I guess it's possible that the second unit's guide has new data out to July 4th, then old (yesterday's) data through July 7th. Again, there is really no way to tell; I don't know what the DVR+ does if it only gets a partial guide update.
I'm going to get a Makers and 7, and then I will be back to look at this. I always wondered how it would do with concurrent updates - I thought PiGS had half a chance. The schedule list (MasterAiringList[] in ls.py) is one loonnggg list in date-time order. The ListIndex is the index x into that array/list. after a dvr makes a request, i just leave the index where was because it will be in the correct place when the same dvr makes its next call. The resetting LI to 0 happens when a time is requested before the time that the LI points to, so I reset the LI to 0 and search from the beginning - slower response, but thought it might work!

Your clocks are not off, that is when DVR+ finished getting the guide data.

DVR+ always gets a 'partial guide update' in the general sense. it ask for up to 14-days of data and displays whatever it gets. if pigs has no more data, it sends dvr+ an empty list [] and dvr+ stops asking then.

V97... what about 98, 99???? :) So, after looking a bit, one thing I did not plan for is dvr 1 advancing the list index AHEAD where dvr 2 'expects' or assumes the index would be. I wouldn't be surprised if there were some 1-4 hr gaps in your schedule on one or both dvrs because some listings got skipped.

the logs shows connection a reset but I'm not sure if the dvr did it or pigs did it. it doesnt seem to link to a particular pigs file - it might be an async ethernet error of some type. i am not a network expert.
File "/usr/lib/python3.5/socket.py", line 576, in readinto
return self._sock.recv_into(b)
ConnectionResetError: [Errno 104] Connection reset by peer
Here is dvr189 right before the error

MAIN:**** Program Schedule request from ('192.168.1.189', 48620).
LS:StaleCheck: Last Built 2020-06-25 22:11:04.513162 Stale(0)
LS:GLS:Searching for 2020-07-04T00:00:00Z. InProgessFlag=0...

Then when dvr 189 woke back up 3 minutes later and tried to continue where it left of, the pigs listindex was at the end (b/c of dvr194) and pigs told dvr189 i have no more for you.

MAIN:**** Program Schedule request from ('192.168.1.189', 48621).
LS:StaleCheck: Last Built 2020-06-25 22:11:04.513162 Stale(0)
LS:GLS:Searching for 2020-07-04T00:00:00Z. InProgessFlag=0...


So the fix... I dont want to start the search at 0 for your 19853 total programs each time a dvr makes a request, so instead of resetting LI to zero, I will start every search backwards from the current location (which could get back to zero) until I find the requested time slot, and then let it take off from there. it should actually be faster than resetting to 0.

i dont know why you get 403 errors on both DVRs. 194 appear to have complete successfully, except for some possible listing gaps, and I wouldn't expect dvr+ to be that smart.

Good find. i will fix up ls.py and send you a new one. it should drop in to v97 or v99

And a little bit later.............


Code:
        # Fixing Frank70's multiple dvr's at the same time bug.
        # In case another dvr or request has advanced the ListIndex beyond this requests time,
        # search backwards until I find a listing before the rst, or I get to the beginning of the list 
        lis = ListIndex             # remember where we started for logging info
        while (ListIndex > 0 ) :    # search, but not before the start of the list.

            #get program airing start time string like "2020-03-08T08:00:00Z"
            pss = MasterAiringList
[ListIndex]['AiringTime']
            #prog start time pst
            pst = parser.parse( pss )
            # if the Program Start time pst is before the requested start time rst, were are done
            if (pst < rst) : break      # out of the loop
            
            ListIndex -= 1    # back up 1 listing and check again.
        
        bkup = lis - ListIndex 
        if (bkup) > 1 :   # 1 would be normal for a 1-dvr sequential request
            logging.info('LS:GLS:Request time before current ListIndex(%d).  Backed up %d listings.', ListIndex, bkup )
So this free PiGS software is about learning... How did I test this? I went to #14 more pigs fun and requested schedule data right from a browser

The first request takes a long time and may even time-out because the request triggers the SD schedule build, which takes 30+ seconds or more.

192.168.1.200/linearschedule/99999/info?duration=30&inprogress=true&startdate=2020-06-14T16:00:00Z

INFO:root:LS:StaleCheck: Last Built 2020-06-26 03:28:32.801910 Stale(0)
INFO:root:MAIN:**** Program Schedule request from ('192.168.1.200', 59750).
INFO:root:LS:StaleCheck: Last Built 2020-06-26 03:28:32.801910 Stale(0)
INFO:root:LS:GLS First Request at: 2020-06-25 22:28(CDT)
INFO:root:LS:GLS:Searching for 2020-06-26T16:00:00Z. InProgessFlag=1...
INFO:root:LS:GLS:Request complete! 29 Listings. LI=1600 Elapsed= 00:00s

Got 29 listings. The ListIndex ended at x=1600 (not time 16:00)

I can now make the same request again because it is before the current ListIndex (this time I said I dont want InProgress shows)

192.168.1.200/linearschedule/99999/info?duration=30&inprogress=false&startdate=2020-06-14T16:00:00Z

INFO:root:MAIN:**** Program Schedule request from ('192.168.1.200', 59750).
INFO:root:LS:StaleCheck: Last Built 2020-06-26 03:28:32.801910 Stale(0)
INFO:root:LS:GLS:Request time before current ListIndex(1571). Backed up 29 listings
INFO:root:LS:GLS:Searching for 2020-06-26T16:00:00Z. InProgessFlag=0...
INFO:root:LS:GLS:Request complete! 28 Listings. LI=1600 Elapsed= 00:46s

This time only 28 listings, not because I backed up, but because the first time I asked for InProgress shows, the second time I did not.

I suppose we should watch for those Network connection resets, but it appear by the logs that dvr189 was attempting to recover from the error all by itself.
Yes if you leave your server off for more than 24 hours then both dvr's will be asking for data when you start pigs.
You could delete your pigs.log and start fresh. You could log at debug level, but I dont think it is necessary - Info level gave us what we needed.
 

·
Registered
Joined
·
1,680 Posts
I'm going to get a Makers and 7, and then I will be back to look at this. I always wondered how it would do with concurrent updates - I thought PiGS had half a chance. The schedule list (MasterAiringList[] in ls.py) is one loonnggg list in date-time order. The ListIndex is the index x into that array/list. after a dvr makes a request, i just leave the index where was because it will be in the correct place when the same dvr makes its next call. The resetting LI to 0 happens when a time is requested before the time that the LI points to, so I reset the LI to 0 and search from the beginning - slower response, but thought it might work!
It was working for quite a while, a minute or two. Then I think what happened is that a new request came in from one of the units while the previous request (from the other unit) was still in progress and something went wrong (the ConnectionResetError).

Back in the day, I wrote TCP server code (using ad-hoc protocols and ad-hoc ports) and there were two ways to do things. You could service one TCP connection at a time on a single thread, in which case subsequent connections would just queue up at the network level and get serviced eventually when the previous connection had been fully processed; Or, for a more responsive server, you could spawn a separate thread to process each TCP connection so the listening thread was never busy for very long. Either method worked. But in this case something is clobbering the TCP connection (or it could have been a one-off anomaly that will never happen again). I may get a chance to test this again tomorrow by forcing a guide refresh on each DVR+ at close to the same time (there's only one of me and they're in different rooms :)).
 

·
Registered
Joined
·
182 Posts
Discussion Starter #37
It was working for quite a while, a minute or two. Then I think what happened is that a new request came in from one of the units while the previous request (from the other unit) was still in progress and something went wrong (the ConnectionResetError).

Back in the day, I wrote TCP server code (using ad-hoc protocols and ad-hoc ports) and there were two ways to do things. You could service one TCP connection at a time on a single thread, in which case subsequent connections would just queue up at the network level and get serviced eventually when the previous connection had been fully processed; Or, for a more responsive server, you could spawn a separate thread to process each TCP connection so the listening thread was never busy for very long. Either method worked. But in this case something is clobbering the TCP connection (or it could have been a one-off anomaly that will never happen again). I may get a chance to test this again tomorrow by forcing a guide refresh on each DVR+ at close to the same time (there's only one of me and they're in different rooms :)).
There is a 'threaded http server' I could use, but i didnt really know why I would want it. maybe this is why????
 

·
Registered
Joined
·
182 Posts
Discussion Starter #38
You might want to bump up the verbosity on the logging to see if you can track down the issue. Drop it back when solved.
Here is the systemd reference that made me think we dont know the real network state
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
where it said: "Cut the crap! How do I make sure that my service starts after the network is really online?"

This started with me wanting to print the pigs static IP in the logs. I found some code to do that.
Then when the crashes were happening, I modified that code to wait for network ready.

Code:
    for i in range(NetworkAttempts, -1,-1) : # start, stop 1 before, step
    
        s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
        try:
            # doesn't even have to be reachable
            s.connect(('10.255.255.255', 1))
            IP = s.getsockname()[0]
        except Exception as err:
            logging.debug("  get_ip = %s", err )
            IP = None
        finally:
            s.close()
    
        if IP :        # If we get real IP, break out of wait loop
            break
        
        logging.info("  Waiting for network %d", i )
        time.sleep(1)      # take a nap while the system boots the Network 

    time.sleep(1)      # take a nap while the system boots the Network 

    return IP
I did log more details, which is what led to the wait time... this is what I saw

Code:
INFO:root:MAIN: PiGS started at 2020-06-25 21:02(CDT)
WARNING:root:MAIN: PiGS Version V1.00 2020-Jun-xx
INFO:root:MAIN: Current Working Directory /home/pi
DEBUG:root:  get_ip = [Errno 101] Network is unreachable
INFO:root:  Waiting for network 30
DEBUG:root:  get_ip = [Errno 101] Network is unreachable
INFO:root:  Waiting for network 29
DEBUG:root:  get_ip = [Errno 101] Network is unreachable
INFO:root:  Waiting for network 28
INFO:root:MAIN: PiGS IP = 192.168.1.200
INFO:root:MAIN: Using Port = 80
 

·
Registered
Joined
·
2,163 Posts
For those who don’t want to purchase a Pi device, you could utilize an old PC by installing MX Linux 19.2. I recommend MX Linux because it is one of the few Linux distros that doesn't bind systemd to port 53 (DNS) which would create a conflict with dnsmasq.

PiGS can be set to autostart by adding the following line to the end of the etc/init.d/rc.local file:

python3 /path to pigs directory/pigs.py 80

I have tested PiGS on an old laptop with MX Linux and it worked fine.

I would still prefer to go the WIN10 route but I have an old lenovo laptop that I installed AntiX Linux on because it was one of the few distros that supported the hardware on it. Do you know if this distro doesn't bind systemd to port 53 etc? I really don't do much of the terminal command line stuff in linux and mostly work with the windows like interface.
 

·
Registered
Joined
·
2,163 Posts
I have gone over the spreadsheet that Timothee put together and now am starting to have questions:


It is not clear to me under "Pigs Way" section if the DVR+ has to have any changes made to it to use PIGS. Do I change zip codes etc?



Also what prevents the DVR+ from going to CM for the guide even in a PIGS environment unless the PIGS PC or raspberry is on 24 hours a day 7 days a week? That is not clear.


I would prefer not to have a PC on 24 hours a day 7 days a week and only bring it up when I actually need to or if I want to update the DVR+ 14 schedule which may only be once or twice a week. So is that a problem?
 
21 - 40 of 539 Posts
Top