Summary: Guide stops 7/15/2015 - Page 2 - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
 8Likes
Reply
 
Thread Tools
post #31 of 63 Old 08-01-2015, 11:05 PM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by cap_ncrunch View Post
It would be nice if you could look into the clock update issue. I believe the servers for replaytv.net were provided by DNNA and will be shut down, if they haven't been shut down already.

I wrote you the evidence that the clock update is working perfectly for me, and you said that you would check your WiRNS log to see what's going on. I can't do anything more without some kind of feedback...


I posted on Planet Replay today that the 4Ks at least do not like the time coming back from DNNA for some reason, but I have little interest in figuring out why because I wouldn't be able to do anything about it...


Henry
hdonzis is offline  
Sponsored Links
Advertisement
 
post #32 of 63 Old 08-02-2015, 02:40 PM
Member
 
cap_ncrunch's Avatar
 
Join Date: Jun 2011
Posts: 82
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 12
Setting the Clock

Occasionally, I find messages in the log that reference replaytv.net:

[8/1/2015 16:08:26] [DNS] Returning 192.168.1.3 for production.replaytv.net to 192.168.1.200
[8/1/2015 16:08:27] [PLUGIN] LoginLogout Skipping Login (nightly, attempts: 5) for 192.168.1.200
[8/1/2015 16:08:28] [DNS] Returning 192.168.1.3 for ntp-production.replaytv.net to 192.168.1.200
[8/1/2015 16:08:28] [NTP] Proxying request to north-america.pool.ntp.org for 192.168.1.200
[8/1/2015 16:08:45] [NTP] Proxying request to north-america.pool.ntp.org for 192.168.1.200
[8/1/2015 16:09:03] [NTP] Proxying request to north-america.pool.ntp.org for 192.168.1.200
[8/1/2015 16:09:20] [NTP] Proxying request to north-america.pool.ntp.org for 192.168.1.200
[8/1/2015 16:09:36] [PLUGIN] ZipcodeProvider: Added 1 lineup for 192.168.1.200.
[8/1/2015 16:09:37] Hijacking headend request for WiRNS lineup 1 from 192.168.1.200, because we serve it locally with 68 channels.
[8/1/2015 16:09:39] Serving guide data for: 2015-08-01 to 192.168.1.200

Note that production.replaytv.net: and ntp-production.replaytv.net are both in this log, as in your log. I don't know if the clock got set because it was set quite accurately beforehand. Usually, these references are not there.



I do note that the machines seem to hang on "Setting the clock" but then move on.


I know that we can't depend on the replaytv.net servers indefinitely. I would be preferable for WiRNS to set the clock but, if not, I am OK with manually adjusting the clock maybe once a week or so, depending on how much it drifts.


The line simulator (a used Lineman from Digital Products Co.) was delivered yesterday. As a retired telecom engineer, I find it fascinating to play around with a 2 line CO in a box. I was troubleshooting some problems with intermittent failures that were occurring before I got the line simulator. I was hoping that the line simulator would clear them up. I have switched over to a modem card in place of the plug-in modem. I have a number of cards, so I'll try swapping them out to try to find one that works consistently.


Thanks, again, for all your help!
cap_ncrunch is offline  
post #33 of 63 Old 08-02-2015, 11:17 PM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by cap_ncrunch View Post
Occasionally, I find messages in the log that reference replaytv.net:

[8/1/2015 16:08:26] [DNS] Returning 192.168.1.3 for production.replaytv.net to 192.168.1.200
[8/1/2015 16:08:27] [PLUGIN] LoginLogout Skipping Login (nightly, attempts: 5) for 192.168.1.200
[8/1/2015 16:08:28] [DNS] Returning 192.168.1.3 for ntp-production.replaytv.net to 192.168.1.200
[8/1/2015 16:08:28] [NTP] Proxying request to north-america.pool.ntp.org for 192.168.1.200
[8/1/2015 16:08:45] [NTP] Proxying request to north-america.pool.ntp.org for 192.168.1.200
[8/1/2015 16:09:03] [NTP] Proxying request to north-america.pool.ntp.org for 192.168.1.200
[8/1/2015 16:09:20] [NTP] Proxying request to north-america.pool.ntp.org for 192.168.1.200
[8/1/2015 16:09:36] [PLUGIN] ZipcodeProvider: Added 1 lineup for 192.168.1.200.
[8/1/2015 16:09:37] Hijacking headend request for WiRNS lineup 1 from 192.168.1.200, because we serve it locally with 68 channels.
[8/1/2015 16:09:39] Serving guide data for: 2015-08-01 to 192.168.1.200

Note that production.replaytv.net: and ntp-production.replaytv.net are both in this log, as in your log. I don't know if the clock got set because it was set quite accurately beforehand. Usually, these references are not there.



I do note that the machines seem to hang on "Setting the clock" but then move on.


I know that we can't depend on the replaytv.net servers indefinitely. I would be preferable for WiRNS to set the clock but, if not, I am OK with manually adjusting the clock maybe once a week or so, depending on how much it drifts.

Well, there's no question that your clock was set on 8/1 by WiRNS, so that appears to be working. However, you can see that the time sets are taking a pretty long time, almost 20 seconds each, which is incredibly long (which is why it is hanging on setting clock for so long). Your problem might be with using that pool NTP server, and it could be that when the clock doesn't get set it's because that server isn't responding. I might recommend you see if you can't find some other time server to use instead, you can see that my time setting is only taking a second, versus yours taking over a minute. You could try using one of the NTP servers in the Windows Internet time choices...

Quote:
Originally Posted by cap_ncrunch View Post
The line simulator (a used Lineman from Digital Products Co.) was delivered yesterday. As a retired telecom engineer, I find it fascinating to play around with a 2 line CO in a box. I was troubleshooting some problems with intermittent failures that were occurring before I got the line simulator. I was hoping that the line simulator would clear them up. I have switched over to a modem card in place of the plug-in modem. I have a number of cards, so I'll try swapping them out to try to find one that works consistently.

I'm also using a 2-line simulator, but I'm sticking with the external modem, especially since I'm using a Laptop for Freesco. But, I'm surprised you switched over to a modem card since you said you wanted to be able to control the volume and the external modem had the volume knob. Anyway, my setup is quite stable!


Henry
hdonzis is offline  
Sponsored Links
Advertisement
 
post #34 of 63 Old 08-03-2015, 09:57 AM
Member
 
cap_ncrunch's Avatar
 
Join Date: Jun 2011
Posts: 82
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 12
I was having problems with the modem disconnecting during the synchronization phase, so installed the internal modem as part of my troubleshooting effort. I found out today that I had not changed DELAY2 in the mgetty script to 600 when I changed PHONESIM to y. I made the change, rebooted FreeSCO and have performed over 10 connect attempts successfully so far. The only problem I had was with a Showstopper reporting that "the modem hung up" one time late in the data transfer cycle. I occasionally got that message when connecting to DNNA's servers, so I will just live with it.

I haven't reverse engineered the mgetty script. I would think that the, previously, 30 seconds would start when the modem answers the call or when the modem sends the RING text string, but that may not be the case. If not, the answer might occur late in the 30 seconds, not giving the modems enough time to synchronize before the computer modem gets sent a command to hang up. By increasing that time to 600 seconds, the chances that the incoming call will come toward the end of 600 seconds are significantly reduced.

I may go back to the external modem for the benefits you mention, but I'll leave things alone for now.

I am confused about how to configure GetNextCall, which I assume is the time that the first Showstopper attempts to call and get a schedule update. On my setup, that time is set as 11:00 AM. The call-in spacing between Showstoppers is 8 minutes, as you thought. I thought that time was set in Updater but it defaults to 3:00 AM and I didn't change it.
cap_ncrunch is offline  
post #35 of 63 Old 08-03-2015, 04:02 PM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by cap_ncrunch View Post
I am confused about how to configure GetNextCall, which I assume is the time that the first Showstopper attempts to call and get a schedule update. On my setup, that time is set as 11:00 AM. The call-in spacing between Showstoppers is 8 minutes, as you thought. I thought that time was set in Updater but it defaults to 3:00 AM and I didn't change it.
There are two different ways to do it, either an amount of time after WiRNS downloads the guide updates, or at a fixed time. Kind of hard to say the difference in those two, I like using a fixed time for the next calls. The problem is that you can only change it for the next net connect, so it's not like if the guide update takes a long time, or has a hiccup, which happened to me this morning, that it can change the RTVs calling in, which had already been scheduled previously. So, the only thing it can do is adjust the net connect for next time...

Anyway, either you fill in how much time you want to wait after the WiRNS guide update, using the "Next Call Start Time", or you check mark "Force Next Call Time" and set the time you want the net connects to start...

Henry
hdonzis is offline  
post #36 of 63 Old 08-04-2015, 04:09 PM
Newbie
 
Join Date: Aug 2015
Posts: 1
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 0
Thumbs up PERC/LaHo is the perfect answer for me. It couldn't be much easier

I'm sure that my post is probably just another similar post to others. But, I wanted to put in my two cents. Like many folks that have posted in this thread, I was never a member of the forum, but read it quite often during the years to get the latest info on my ReplayTV unit. So, while this is my first post, it's definitely not my first time visiting this very informative forum. I, like many others, thank the guys that have kept this thing up over the years. I started out more than 10 years ago with a Panasonic Showstopper unit. I upgraded the hard drive in that and it performed great for many, many years. But, eventually.......like about the time back in 2011 or 2012 when the folks at ReplayTV threatened to stop their online program guide service, we started having terrible trouble around my area (central VA) with being able to connect via dial-up. But, as we all know, they eventually changed their mind and reinstated their online program guide until just recently. But, because I was having so much problem with dialup back then, I upgraded to one of the ReplayTV 5040 units that used an Ethernet connection and connected through the internet. That was a good move and I never had any problems connected and downloading the program guide again until 7/15 when we all know that the guide ceased for good and the parent company DNNA filed for bankruptcy. Like a lot of folks, I wasn't sure what to do. Should I just junk my units and make the expensive upgrade to something like TIVO or what? For more than two weeks, I did everything as manual recordings. I would go back and forth between the Comcast Guide ( I have Comcast) and the Replay TV unit to make the settings. It worked fine and I might have continued doing that.......but, as many other folks may have also found out, it's pretty time consuming and you really don't know what you have recorded unless you go in and rename each of those manual recordings. But, it worked fine for the past few weeks and, as far as I can tell, my unit was still able to call in each night and connect to the old ReplayTV system to at least set the clock, which is important to being able to continue using the manual record. Don't know how long that will last......but, it still seemed to be working a day or two ago.

But, quite honestly, I was getting pretty tired of doing the manual recordings each night. What used to be a two or three minute process each night, was starting to be more like a 15 or 20 minute process.....or, longer. So, I found myself really looking for a better alternative. I don't have an extra spare windows computer and, quite honestly, the whole WiRNS thing that I have been reading about on here just seemed a little bit more complicated than I really wanted to deal with. So, I started looking pretty closely at this PERC/LaHo system that has been mentioned on here quite a few times. I have to say, I was expecting something that was going to be both more complicated than I wanted to deal with and probably more expensive too. But, I was very pleasantly surprised when I sat down yesterday and gave it a try. They give you a free 7 day trial period to make sure that it works properly for you and that you like what you are getting from them. When you go to their website (via the link shown on the first post in this thread), you will find very detailed and easy to read instructions (with screen shots) that are easy to follow and work pretty much exactly like they describe. It's really easy and, within about 20 minutes, I was back to having a ReplayTV Guide that looked nearly identical to what I was used to seeing. I was impressed. It's only been a couple of days, so I haven't plunked down any bucks yet.......but, from what I've seen so far, I really don't expect to have any problems at all. I have noticed a couple of very minor differences so far. For instance, most of the programs in the online guide used to show either "repeat" or "new", which made it very easy to know if something was being shown for the first time on that particular network. From what I've seen so far with this PERC/LaHo guide, it still shows "repeat"......but, if it's new, it doesn't say new. It just has the description without either new or repeat shown. No big deal, just a minor difference that I noticed. Also, during the day today, I decide to make it connect and download manually just as a test. It did connect and it did download everything as it was supposed to........but, it seemed to take about three times longer than usual......at least, as compared to how long it took on the old ReplayTV network. I don't know if this is typical or just a slow period. It definitely wasn't the first time connecting to this network........and, it didn't really cause me any problem.......but, it was noticeably slower. But, beggers can't be choosers and I don't see where this would cause me any problems. Even being slower than it was, I'm still not talking more than about 10 minutes or so. Definitely, nowhere as long as dialup used to take.

I've read several folks on here that have complained that they bought something with a guaranteed "LIFETIME" subscription to the service and they didn't think that they should have to pay for another service. I understand that feeling. But, let's face it, it's over with ReplayTV and, quite honestly, we're probably all really lucky that it continued this long. If this were a service that was trying to charge us $10, $12....maybe even $15 per month to get the guide for one ReplayTV unit, then I doubt seriously that I would have even tried it. If I'm going to pay that kind of money, I'll go buy a new Tivo unit or something newer and more high tech. But, the good news is, that these folks are being very reasonable and I don't see how anyone can complain about the price that they are asking for this really well done service to keep our old ReplayTV units going for a few more years. For those that haven't checked it out yet, we're talking about a total of $21 for 6 months access. For those of you without a calculator handy, that's only $3.50 per month. And, as I said, they give you a full 7 day trial period first before you have to pay anything or even give them your credit card info. If you ask me, that's a pretty great deal. If the service continues to be as good as it has seemed for this first two days, I think $3.50 is a very affordable and very reasonable price to keep my good old ReplayTV 5040 unit going a little bit longer. Maybe only a few months until I finally decide that being able to record in high def is worth what I have to spend with Tivo.........or, I could still be using it a year or two from now. At least for me, this is the answer and I wanted to share in case there is anyone else out there in a similar situation that might could benefit from my experience.

I want to thank each and every person that has posted on this forum over the years about the ReplayTV problems and, especially, in this newest thread about this most recent problem. If it weren't for this forum, most of us would not really know that there is an alternative.


Thanks
bryanray is offline  
post #37 of 63 Old 08-04-2015, 10:07 PM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by bryanray View Post
For instance, most of the programs in the online guide used to show either "repeat" or "new", which made it very easy to know if something was being shown for the first time on that particular network. From what I've seen so far with this PERC/LaHo guide, it still shows "repeat"......but, if it's new, it doesn't say new. It just has the description without either new or repeat shown

This is the way that the ReplayTV has always operated. The guide showing "new" is somewhat recent, certainly more recent than ReplayTV has been doing any software development. The ReplayTV does not have the ability to show "new", only "repeat". However, you can schedule the 5K ReplayTV to record what you consider new airings by using the "First run episodes" recording option, which will skip recording shows marked as "repeat". And, you can tell by the normal recording method saying "First runs and repeats" that the ReplayTV operates using the "repeat" indicator...


Thanks for your kind words about your usage of LaHo!


Henry
hdonzis is offline  
post #38 of 63 Old 08-05-2015, 10:46 PM
Member
 
cap_ncrunch's Avatar
 
Join Date: Jun 2011
Posts: 82
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 12
I also appreciate brianray's fine post about his experiences regarding loss of the guide service. I kept with my Panasonic Showstopper dial-in machines and am, hopefully, putting the final touches on my WiRNS/FreeSCO/SchedulesDirect configuration. Thanks to Henry for his fine help!

The simplest way I've found to silence the modem speaker is to append M0 to the init string for the modem. In my case, it becomes AT&F0M0. This is configured from the setup command in the FreeSCO virtual machine.

For those with more than one active Showstopper (I have 4): The standard WiRNS spacing for call-in times is 8 minutes, which is not enough for the Showstoppers. I've added 2 fake machines between active machines, to space the times out to 24 minutes. Thus, each machine must be able to call-in, download a complete schedule update, and drop off before 24 minutes in up to avoid overlap and failed download for it and the next machine.. If that turns out not to be enough, I can add fake machines to build out more time in additional 8 minute increments.

The machines are ordered alphabetically by the names the user gives them. Thus, extra fake machines can be inserted between real machines just by choosing fake names that fall alphabetically between the real machines already in your list. It is not necessary to delete machines and rebuild the list.

You can dedicate a computer as a WiRNS/FreeSCO host and leave it on all the time, or run from a computer used for something else. For the time being, I'll use my main home computer that is normally turned off overnight. I'll schedule a block of time in the morning for updates, starting at about 8 AM, before any recordings are scheduled. I run Windows XP and use the hibernate feature when I shut down. I find that I must reboot the FreeSCO virtual machine after I power up in the morning or the calls don't connect to WiRNS.

A dedicated computer could be powered through a timer. It would not get a graceful shutdown, just having its power cut off. It would need to boot up and download the schedule updates before the Showstoppers start calling in. There is a way to put a command in the startup folder to launch the virtual machine.

I am currently using a telephone line simulator and an internal modem that requires line current. The line current is supplied by the simulator. The internal modem does not have a relay, connecting to the phone line with "solid state" devices instead.
cap_ncrunch is offline  
post #39 of 63 Old 08-06-2015, 06:50 PM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by cap_ncrunch View Post
For those with more than one active Showstopper (I have 4): The standard WiRNS spacing for call-in times is 8 minutes, which is not enough for the Showstoppers. I've added 2 fake machines between active machines, to space the times out to 24 minutes. Thus, each machine must be able to call-in, download a complete schedule update, and drop off before 24 minutes in up to avoid overlap and failed download for it and the next machine.. If that turns out not to be enough, I can add fake machines to build out more time in additional 8 minute increments.

The machines are ordered alphabetically by the names the user gives them. Thus, extra fake machines can be inserted between real machines just by choosing fake names that fall alphabetically between the real machines already in your list. It is not necessary to delete machines and rebuild the list..

I updated WiRNS to double the time between dial-up units, which you can read about here: http://www.planetreplay.com/phpBB2/v...?p=85905#85905. I only doubled the time between units instead of tripling it because I looked at my Showstopper's net connect time, and it is less than 2 minutes. So, I figured that 24 minutes was kind of overkill, that 16 minutes should be adequate...


So, you can update WiRNS and delete your "fake" units and see how it works. If it turns out it isn't enough time, at least now I can change the amount of delay between dial-up units independently from networked units, which I'm happy with...


Henry
SD_Shadow likes this.
hdonzis is offline  
post #40 of 63 Old 08-07-2015, 01:12 PM
Member
 
cap_ncrunch's Avatar
 
Join Date: Jun 2011
Posts: 82
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 12
I looked at the planetreplay discussion and am impressed with how much effort you've put into WiRNS to do bug fixes and feature enhancements, Henry!

If users have just one Showstopper, the time between scheduled updates is, of course, not an issue. I don't know how many users have 2 or more Showstoppers, but doubt that the number is significant.

I am still using WiRNS 2.1.0.0. I had updated, but I am little too much of a tinkerer and really got things messed up somewhere along the line, so I uninstalled WiRNS and started over. The main problem I had was losing the schedule and then getting an error message every time I tried to dial out in the Change Telephone sequence. I needed for that to succeed to get the schedule back. Somehow, by reverting back to the earlier WiRNS and experimenting with different Zip codes, I got rid of the error message.

Instead of deleting the fake machines, I'll rename them with a leading Z, so they will fall to the bottom of my list. That way, I can put them back later if needed. I'll also prefix A, B, C and D to the names of my actual machines, in the order that I actually want them to update their schedules. Since 2 machines record some daytime programming and the others don't, I'll put the daytime machines at the top of my list, which starts schedule updates at 8 AM.

In spite of having this bad experience and running the risk of having it happen all over again, my temptation to tinker will get the best of me and I will be updating WiRNS in the next few days. The updated WiRNS does change the "Change Telephone" choices, deleting ReplayTV's menu of phone numbers and offering 1 fake number for Any Town, USA, and only offering WiRNS (schedules) and "Other."

My 4 machines updated this morning and the longest any one of them took was about 10 minutes after, maybe, a minute or two to dial, wait for the computer modem to answer, and handshake (synchronize the modems). For reference, when you "Change Telephone" and then "Keep all settings", the screen message gives a 20 minute estimate, but that is for a full schedule download. In practice, 16 minutes should be adequate for normal (incremental) updates.

If a full schedule must be downloaded, for example because the computer running WiRNS was shut down for a week, I feel that the 16 minutes will be exceeded, especially if the user has configured a large number of channels and/or the user's computer modem doesn't support the highest rates.

With the computer modem that I am using, the connection drops when another machine tries to connect. I haven't experimented with different modems to see if I can find one that will recover. It seems the late model telephone modem designs would recover if someone picked up a phone and quickly hung back up when a computer was using the home telephone line. It also seems, when I was connecting to DNNA at night, that the other machines would not report an error when one machine reported "no dial tone", indicating that it had tried to access the line when it was in use. If the internal Showstopper modem and the computer modem can recover, then the multiple machines would catch up, one day per machine, since the first machine taking a long time for a full download would only need to be updated the second day and not overlap the second machine's session on the second day, etc.

If the user dedicates a computer to WiRNS/FreeSCO and leaves it running 24/7, the schedule updates can take place late at night and be spaced far enough apart to allow them to complete in the very worst case scenario of a vacant guide and lots of channels. For someone like myself, who would like to use a computer that is not powered up continuously and do the updates during a specific time slot during the day, spacing them closer together makes the best sense.

So, bottom line, the new 16 minute time spacing between dialup machines is probably fine. Two possible enhancements: 1) automatically increase the spacing from 16 minutes to, maybe, 45 or 60 minutes, if the updates are scheduled to take place late at night (midnight to 6 AM) or 2) make the spacing a user configurable parameter defaulting to 16 minutes.
cap_ncrunch is offline  
post #41 of 63 Old 08-07-2015, 05:41 PM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by cap_ncrunch View Post
In spite of having this bad experience and running the risk of having it happen all over again, my temptation to tinker will get the best of me and I will be updating WiRNS in the next few days. The updated WiRNS does change the "Change Telephone" choices, deleting ReplayTV's menu of phone numbers and offering 1 fake number for Any Town, USA, and only offering WiRNS (schedules) and "Other."

It depends on how you install WiRNS3, same for WiRNS2. Remember that for WiRNS2, it requires ReplayTV to be around for it to talk to and let your units talk to. For WiRNS2, if you don't have a plugin installed to intercept any part of the net connect, then it simply allows that to go through to ReplayTV. So, if you have no "phone number" plugin installed, then you got the phone numbers from ReplayTV (which really doesn't serve much purpose for a dial-up unit ending up calling WiRNS). However, if you install the WiRNS2 NoPhoneNumbers plugin, then it would have also supplied your unit with the exact same "fake" phone number that you saw with WiRNS3. So, unlike the other No... plugins for WiRNS2 which are meant to make the net connect go faster, like NoReplayZones, you normally wouldn't install anything to prevent the phone number communication, you would only install this plugin if you wanted to change the phone number...


However, for WiRNS3 you have two choices. It can never give you the choice of connecting to ReplayTV since the premise of WiRNS3 is that ReplayTV has gone away, but it has two phone number plugins. It has NoPhoneNumbers, which actually tells the unit to just leave the phone number alone like you want (except that I don't know if the RTV likes that or not, it certainly doesn't like that when you change your dialing code), and it has MyPhoneNumbers, which is the one that allows you to set the phone number...


You have to understand, if there's no ReplayTV and you change your dialing code or anything along those lines, or are going through the quick setup after a reset or reimage or whatever, then something HAS to answer the phone number request. So, for WiRNS3 that is MyPhoneNumbers, and you configure it through the registry with whatever phone number you want it to supply for the "800" number and the local number. But, if you want to try to leave your existing phone number alone for as long as possible, then install NoPhoneNumbers instead on WiRNS3, and that should work fine as long as you don't change the dialing information...

Quote:
Originally Posted by cap_ncrunch View Post
My 4 machines updated this morning and the longest any one of them took was about 10 minutes after, maybe, a minute or two to dial, wait for the computer modem to answer, and handshake (synchronize the modems). For reference, when you "Change Telephone" and then "Keep all settings", the screen message gives a 20 minute estimate, but that is for a full schedule download. In practice, 16 minutes should be adequate for normal (incremental) updates.

If a full schedule must be downloaded, for example because the computer running WiRNS was shut down for a week, I feel that the 16 minutes will be exceeded, especially if the user has configured a large number of channels and/or the user's computer modem doesn't support the highest rates.
Well, I think it already downloads about half the days anyway. With a 7-day guide, the sparse guide update doesn't really save too very much. I just looked, and it downloads three of the days, just short of half. And, for me, it looks like it takes about 30 seconds a day. So, it seems like even if it had to download the entire week, it probably shouldn't be that bad...


I thought about making it 24 minutes just because of the message, but then thought that 16 should be more than adequate. I think their timings were based on the average home user going over a real phone line. And, if someone was going to setup this home phone line setup, why in the world would they not use a 56K modem?


Quote:
Originally Posted by cap_ncrunch View Post
So, bottom line, the new 16 minute time spacing between dialup machines is probably fine. Two possible enhancements: 1) automatically increase the spacing from 16 minutes to, maybe, 45 or 60 minutes, if the updates are scheduled to take place late at night (midnight to 6 AM) or 2) make the spacing a user configurable parameter defaulting to 16 minutes.

I'm not sure I follow why you'd want the spacing to be more if you dial in late at night. Maybe you are thinking that it matters less, but it's also when nothing's going on, so it doesn't seem like it should need more time...


I was originally going to simply add a user configurable parameter to configure the 8 minutes in the first place. But, then I had this idea that if you had a mix of units, then having this automatic configuration would be far superior. Especially if you had more than one dial-up units, but also had network units, why would you want to increase the time between your network units having only one configuration parameter?


Anyway, give it a try and see what you think. I can always bump it to 24 if the 16 minutes isn't enough. Or, I can make just the dial-up parameter be configurable. That's why I'm very happy with making this distinction in the first place, that I can now deal with a mix of network and dial-up units, that I no longer allot net connect time to WiRNS or DVArchive units (since, as you know, they are sequence alphabetically and people don't necessarily name their WiRNS and DVArchive instances something that would push them to the end of the list), so that I can have a separate time for network and dial-up units...


As I started out with, I don't want to make it unnecessarily complicated and I don't want a bunch of configuration parameters. That's why I thought maybe it wouldn't be so good to have the single configuration parameter if you had a mix of networked and dial-up units. But, if it doesn't work out so well, I could certainly make a single dial-up configuration setting, that wouldn't be so bad. Although, my hope is to actually come up with a setting that just works and not have to mess with anything. If you have special circumstances and need to allow additional time, then using the "fake" machines is a pretty good way to go!


Henry
hdonzis is offline  
post #42 of 63 Old 08-07-2015, 07:07 PM
Senior Member
 
mlloyd's Avatar
 
Join Date: Feb 2002
Location: east Texas
Posts: 353
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 51 Post(s)
Liked: 19
Quote:
Originally Posted by hdonzis View Post
It depends on how you install WiRNS3, same for WiRNS2. Remember that for WiRNS2, it requires ReplayTV to be around for it to talk to and let your units talk to. For WiRNS2, if you don't have a plugin installed to intercept any part of the net connect, then it simply allows that to go through to ReplayTV. So, if you have no "phone number" plugin installed, then you got the phone numbers from ReplayTV (which really doesn't serve much purpose for a dial-up unit ending up calling WiRNS). However, if you install the WiRNS2 NoPhoneNumbers plugin, then it would have also supplied your unit with the exact same "fake" phone number that you saw with WiRNS3. So, unlike the other No... plugins for WiRNS2 which are meant to make the net connect go faster, like NoReplayZones, you normally wouldn't install anything to prevent the phone number communication, you would only install this plugin if you wanted to change the phone number...


However, for WiRNS3 you have two choices. It can never give you the choice of connecting to ReplayTV since the premise of WiRNS3 is that ReplayTV has gone away, but it has two phone number plugins. It has NoPhoneNumbers, which actually tells the unit to just leave the phone number alone like you want (except that I don't know if the RTV likes that or not, it certainly doesn't like that when you change your dialing code), and it has MyPhoneNumbers, which is the one that allows you to set the phone number...


You have to understand, if there's no ReplayTV and you change your dialing code or anything along those lines, or are going through the quick setup after a reset or reimage or whatever, then something HAS to answer the phone number request. So, for WiRNS3 that is MyPhoneNumbers, and you configure it through the registry with whatever phone number you want it to supply for the "800" number and the local number. But, if you want to try to leave your existing phone number alone for as long as possible, then install NoPhoneNumbers instead on WiRNS3, and that should work fine as long as you don't change the dialing information...



Well, I think it already downloads about half the days anyway. With a 7-day guide, the sparse guide update doesn't really save too very much. I just looked, and it downloads three of the days, just short of half. And, for me, it looks like it takes about 30 seconds a day. So, it seems like even if it had to download the entire week, it probably shouldn't be that bad...


I thought about making it 24 minutes just because of the message, but then thought that 16 should be more than adequate. I think their timings were based on the average home user going over a real phone line. And, if someone was going to setup this home phone line setup, why in the world would they not use a 56K modem?





I'm not sure I follow why you'd want the spacing to be more if you dial in late at night. Maybe you are thinking that it matters less, but it's also when nothing's going on, so it doesn't seem like it should need more time...


I was originally going to simply add a user configurable parameter to configure the 8 minutes in the first place. But, then I had this idea that if you had a mix of units, then having this automatic configuration would be far superior. Especially if you had more than one dial-up units, but also had network units, why would you want to increase the time between your network units having only one configuration parameter?


Anyway, give it a try and see what you think. I can always bump it to 24 if the 16 minutes isn't enough. Or, I can make just the dial-up parameter be configurable. That's why I'm very happy with making this distinction in the first place, that I can now deal with a mix of network and dial-up units, that I no longer allot net connect time to WiRNS or DVArchive units (since, as you know, they are sequence alphabetically and people don't necessarily name their WiRNS and DVArchive instances something that would push them to the end of the list), so that I can have a separate time for network and dial-up units...


As I started out with, I don't want to make it unnecessarily complicated and I don't want a bunch of configuration parameters. That's why I thought maybe it wouldn't be so good to have the single configuration parameter if you had a mix of networked and dial-up units. But, if it doesn't work out so well, I could certainly make a single dial-up configuration setting, that wouldn't be so bad. Although, my hope is to actually come up with a setting that just works and not have to mess with anything. If you have special circumstances and need to allow additional time, then using the "fake" machines is a pretty good way to go!


Henry
I would like a configurable delay here. As to multiple FREESCO units:

How about intelligent ordering, where WiRNS would schedule dialup units alternately with net-connected units if possible. If not possible, then you could use a longer delay.

For example, starting at 2AM:

1. 2020 at 2:00AM

2. 5060 at 2:08AM (8 minute delay, this unit is not dialup)

3. Showstopper at 2:16AM (8 minute delay, 16 minutes after prev. dialup unit)

4. 3060 at 2:32AM (16 minute delay needed here)

(saved 8 minutes by putting the non-dialup unit in the middle)

Anyway, how were phoneline conflicts handled before?
mlloyd is offline  
post #43 of 63 Old 08-07-2015, 07:58 PM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by mlloyd View Post
I would like a configurable delay here. As to multiple FREESCO units:

How about intelligent ordering, where WiRNS would schedule dialup units alternately with net-connected units if possible. If not possible, then you could use a longer delay.

For example, starting at 2AM:

1. 2020 at 2:00AM

2. 5060 at 2:08AM (8 minute delay, this unit is not dialup)

3. Showstopper at 2:16AM (8 minute delay, 16 minutes after prev. dialup unit)

4. 3060 at 2:32AM (16 minute delay needed here)

(saved 8 minutes by putting the non-dialup unit in the middle)

Anyway, how were phoneline conflicts handled before?

As has been discussed, the ordering by WiRNS is very straightforward, it is alphabetically. And, since you have to make up names for your dial-up units anyway, then you can easily control the order as you have exampled above by simply naming your dial-up units with names that fit between the units that you want. Doesn't seem like it gets much simpler than that...


Henry
hdonzis is offline  
post #44 of 63 Old 08-07-2015, 08:36 PM
Senior Member
 
mlloyd's Avatar
 
Join Date: Feb 2002
Location: east Texas
Posts: 353
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 51 Post(s)
Liked: 19
Quote:
Originally Posted by hdonzis View Post
As has been discussed, the ordering by WiRNS is very straightforward, it is alphabetically. And, since you have to make up names for your dial-up units anyway, then you can easily control the order as you have exampled above by simply naming your dial-up units with names that fit between the units that you want. Doesn't seem like it gets much simpler than that...


Henry
That was a suggestion.

What I'd really like is to be able to arrange the Replays in the order I choose, without playing games with the sorting. For one thing, I use a lot of JIT recordings and it's a lot of work to change EVERY ONE because of Renaming a Replay.
mlloyd is offline  
post #45 of 63 Old 08-07-2015, 09:54 PM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by mlloyd View Post
What I'd really like is to be able to arrange the Replays in the order I choose, without playing games with the sorting. For one thing, I use a lot of JIT recordings and it's a lot of work to change EVERY ONE because of Renaming a Replay.

Not going to happen by me. However, I added being able to configure the delay between units, which I announce here: http://planetreplay.com/phpBB2/viewt...?p=85924#85924...


Henry
hdonzis is offline  
post #46 of 63 Old 08-08-2015, 09:20 PM
Member
 
cap_ncrunch's Avatar
 
Join Date: Jun 2011
Posts: 82
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 12
Based on your comment, Henry, that WiRNS 3 runs independently of ReplayTV and WiRNS 2 doesn't, I've installed WiRNS 3.0.0.0 Beta. I went through Change Telephone on all 4 machines and was able to select the Any Town, USA phone number and the WiRNS guide for my provider.

When I was shopping for telephone line simulators on ebay, there was one that did not support the higher baud rate modems. I believe its upper limit was 28.8 k. Use of this simulator would be a reason why some setups would not run at the fastest baud rate.

As for maximizing the delay between dial-up replays calling in, the goal is to never have the downloads overlap in the worst case of an empty guide with lots of channels and less than optimum baud rate. If you have all night, might as well space the call-ins far apart.

I haven't updated to the most current WiRNS build, while I experiment some more with this one. I still have 2 fake machines between each sequential pair of valid machines.

You can order your machines by prefixing 1-, 2-, 3- etc. or A-, B-, C- to the current names, so I agree with Henry and see no need to add a configuration variable to set up the guide update order
cap_ncrunch is offline  
post #47 of 63 Old 08-08-2015, 09:51 PM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by cap_ncrunch View Post
When I was shopping for telephone line simulators on ebay, there was one that did not support the higher baud rate modems. I believe its upper limit was 28.8 k. Use of this simulator would be a reason why some setups would not run at the fastest baud rate.

That's very interesting because I can't imagine how a phone line simulator could care about the baud rate. It's usually just relays and tone generators and receivers, but all running on copper pair, so I'm not sure what in all of that would limit the baud rate. You'd think once it detects ringing and closes the relay, then it's straight on the wire. Although, the phone line end has to monitor on-hook current and listen for touch tones and such, so maybe there's some kind of possibility that it might not pass through everything it "hears". But, still sounds strange! I guess it would depend on how much of a savings it was...

Quote:
Originally Posted by cap_ncrunch View Post
As for maximizing the delay between dial-up replays calling in, the goal is to never have the downloads overlap in the worst case of an empty guide with lots of channels and less than optimum baud rate. If you have all night, might as well space the call-ins far apart.

Well, I added the registry config option for being able to configure the delay, so you should be able to do what you want...

Quote:
Originally Posted by cap_ncrunch View Post
I haven't updated to the most current WiRNS build, while I experiment some more with this one. I still have 2 fake machines between each sequential pair of valid machines.

That's very bad because you really should not use WiRNS3 without upgrading it first! The version that you downloaded is so very old that it is very buggy. I keep talking to the "guys" about building an up-to-date version, but the installer package seems to have gotten lost, so we're still trying to figure out how to make a newer installer...


Henry
ClearToLand likes this.
hdonzis is offline  
post #48 of 63 Old 08-09-2015, 09:29 AM
Member
 
cap_ncrunch's Avatar
 
Join Date: Jun 2011
Posts: 82
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 12
The Viking DLE-200B line simulator supports a maximum data speed of 28,800 bps, according to its specifications:

http://www.vikingproductstore.com/vi...r_DLE200B.html

For "high speed data," Viking offers model DLE-300.

In my opinion, it seems like poor engineering to release a simulator design into production that doesn't meet the current telephone industry land line voice quality standards required for "high speed" analog data.

The Lineman line simulator, which was purchased from an ebay seller and is made by a different company, claims to support high speed analog data calls.

To be truthful about it, I really got things messed up after I first installed WiRNS 3.0.0.0 Beta. Somehow, the clocks were being set, but were an hour fast. After I did the Check for Updates, I never could get the icon to turn green. So, I uninstalled and started over. I had to re-enter my Replays. Things are working well at the moment. Since the clocks were set to the correct time before the guide updates, I don't know if the clocks are actually being set, but they aren't an hour ahead. I'll try doing WiRNS Updates in another day or two, after proving this one in.

Thanks for all your help, Henry!
cap_ncrunch is offline  
post #49 of 63 Old 08-09-2015, 10:46 AM
Senior Member
 
mlloyd's Avatar
 
Join Date: Feb 2002
Location: east Texas
Posts: 353
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 51 Post(s)
Liked: 19
Quote:
Originally Posted by cap_ncrunch View Post
The Viking DLE-200B line simulator supports a maximum data speed of 28,800 bps, according to its specifications:

http://www.vikingproductstore.com/vi...r_DLE200B.html

For "high speed data," Viking offers model DLE-300.

In my opinion, it seems like poor engineering to release a simulator design into production that doesn't meet the current telephone industry land line voice quality standards required for "high speed" analog data.

The Lineman line simulator, which was purchased from an ebay seller and is made by a different company, claims to support high speed analog data calls.

To be truthful about it, I really got things messed up after I first installed WiRNS 3.0.0.0 Beta. Somehow, the clocks were being set, but were an hour fast. After I did the Check for Updates, I never could get the icon to turn green. So, I uninstalled and started over. I had to re-enter my Replays. Things are working well at the moment. Since the clocks were set to the correct time before the guide updates, I don't know if the clocks are actually being set, but they aren't an hour ahead. I'll try doing WiRNS Updates in another day or two, after proving this one in.

Thanks for all your help, Henry!
I setup a FREESCO system a couple of days ago, and it seems to be working fine.

I'm using the same phone simulator you mentioned (Viking DLE-200B). Maybe the bps limitaion refers to it not being able to handle V.90 (which my 2020 doesn't use, although I think it's supposed to work with 31.2bps). Is there a way to determine what connection speed is being used? It seems a little faster than with a real phoneline (before July 2015). I had just installed new disk image to the Replay, and didn't make any changes in order to use this setup.

It was hard to figure out how to silence the modem. Adding L0 or M0 to the initializaton string didn't work. I had to use a terminal program and write the settings to NVRAM.

I want to use a timer to turn this on only at the proper time. The 2 automatic connects I've had so far were at 2:53AM yesterday and 2:49AM today. I think I heard the range of times is 2AM to 6AM. Does that sound right? Currently I have the timer set to on at 1:55AM (to give FREESCO time to boot) and off at 6:00AM.

BTW, The new clock capacitor I put in seems to be working OK and WiRNS is setting the clock.
mlloyd is offline  
post #50 of 63 Old 08-09-2015, 11:29 AM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by cap_ncrunch View Post
To be truthful about it, I really got things messed up after I first installed WiRNS 3.0.0.0 Beta. Somehow, the clocks were being set, but were an hour fast. After I did the Check for Updates, I never could get the icon to turn green. So, I uninstalled and started over. I had to re-enter my Replays. Things are working well at the moment. Since the clocks were set to the correct time before the guide updates, I don't know if the clocks are actually being set, but they aren't an hour ahead. I'll try doing WiRNS Updates in another day or two, after proving this one in.

That's one of the bugs I'm telling you about the Beta. It was worse if you had upgraded from WiRNS2. There used to be a problem with WiRNS setting the time zone incorrectly if you configured in the summer time, during Daylight Savings Time, that it set the time zone information one hour off. The latest version of WiRNS3 has a pull-down selection for choosing your time zone so that you can get it correct more easily. But, it also shows you what's going to get sent to the Replays, so you can confirm it is correct...


But, the biggest problem was in upgrading from WiRNS2 and not having it set correctly. And, possibly there was a problem with a version of WiRNS3, I can't remember. But, it was enough of a problem that we posted a sticky on the subject here: Time Zone updates, so you should have a look at that thread...


Henry
hdonzis is offline  
post #51 of 63 Old 08-09-2015, 01:36 PM
Member
 
cap_ncrunch's Avatar
 
Join Date: Jun 2011
Posts: 82
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 12
With your encouragement, Henry, I went ahead and updated WiRNS. The icon is green. The update from Schedules Direct was failing this morning, but it works now. I located dialupUnitDelay in the registry and modified it to my previous 24 minutes. Then, I deleted my "fake" machines. If I decide to change the spacing, I need to verify that the all machines have updated their call-in times to the new spacing before the next day's round of call-ins. Otherwise, an "old" call-in time might overlap a "new" one.

The Showstopper clocks are correct. My time zone in WiRNS shows as Pacific (correct) and time zone string as PST8PDT,M3.2.0,M11.1.0. I am assuming that the last part of the string defines the month, week and day of the week (0 = Sunday) when DST begins and ends and can be changed if Congress and the President tinker with it again.

As for mlloyd's question about the baud rate, you can shut down your virtual machine and connect to your modem with hyper terminal. Have a Replay machine make a net connect from 243-Zones. Answer the call using the modem command ATA. Once the modems complete their handshake (synchronization), you may get CONNECT followed by the baud rate. Unfortunately, for me, the rate was for the COM port (more than 115,000 bps) and not the line. There may be a way to get the modem to report the line rate instead. That would take some delving into the AT command set.
cap_ncrunch is offline  
post #52 of 63 Old 08-09-2015, 03:34 PM
Senior Member
 
mlloyd's Avatar
 
Join Date: Feb 2002
Location: east Texas
Posts: 353
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 51 Post(s)
Liked: 19
Quote:
Originally Posted by cap_ncrunch View Post
With your encouragement, Henry, I went ahead and updated WiRNS. The icon is green. The update from Schedules Direct was failing this morning, but it works now. I located dialupUnitDelay in the registry and modified it to my previous 24 minutes. Then, I deleted my "fake" machines. If I decide to change the spacing, I need to verify that the all machines have updated their call-in times to the new spacing before the next day's round of call-ins. Otherwise, an "old" call-in time might overlap a "new" one.

The Showstopper clocks are correct. My time zone in WiRNS shows as Pacific (correct) and time zone string as PST8PDT,M3.2.0,M11.1.0. I am assuming that the last part of the string defines the month, week and day of the week (0 = Sunday) when DST begins and ends and can be changed if Congress and the President tinker with it again.

As for mlloyd's question about the baud rate, you can shut down your virtual machine and connect to your modem with hyper terminal. Have a Replay machine make a net connect from 243-Zones. Answer the call using the modem command ATA. Once the modems complete their handshake (synchronization), you may get CONNECT followed by the baud rate. Unfortunately, for me, the rate was for the COM port (more than 115,000 bps) and not the line. There may be a way to get the modem to report the line rate instead. That would take some delving into the AT command set.
On Windows (HyperTerminal), I get

CONNECT 14400
followed by a little garbage and a quick disconnect.

It's still faster than with DNNA. Maybe this Replay has always been slow.
mlloyd is offline  
post #53 of 63 Old 08-09-2015, 04:50 PM
Member
 
cap_ncrunch's Avatar
 
Join Date: Jun 2011
Posts: 82
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 12
Mark, I really doubt if the line simulator or modem at either end of the connection would limit you to 14,400. If you are using a physical COM port on your computer for an external modem, check to see if the baud rate is set to 14,400. Note that the modem will auto-baud to the data rate of the AT string,. For Windows XP: Control Panel > System Icon > Hardware tab > Device Manager Button > Ports > Comm Port Then check the Port settings for your external modem's Comm Port. Mine had defaulted to 9600. I suppose this number will be the limiting factor. I suggest setting it for 57, 600.

If you are using an internal modem, the COMM port is virtual, not physical, and won't show up on this list.
cap_ncrunch is offline  
post #54 of 63 Old 08-09-2015, 05:08 PM
Senior Member
 
mlloyd's Avatar
 
Join Date: Feb 2002
Location: east Texas
Posts: 353
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 51 Post(s)
Liked: 19
Quote:
Originally Posted by cap_ncrunch View Post
Mark, I really doubt if the line simulator or modem at either end of the connection would limit you to 14,400. If you are using a physical COM port on your computer for an external modem, check to see if the baud rate is set to 14,400. Note that the modem will auto-baud to the data rate of the AT string,. For Windows XP: Control Panel > System Icon > Hardware tab > Device Manager Button > Ports > Comm Port Then check the Port settings for your external modem's Comm Port. Mine had defaulted to 9600. I suppose this number will be the limiting factor. I suggest setting it for 57, 600.

If you are using an internal modem, the COMM port is virtual, not physical, and won't show up on this list.
That may have happened. Hyperterminal asks for a rate at startup. I don't remember what it was the first time, but I tried it again and made sure to set to 57600. The Replay now shows:

CONNECT 28000 V42bis

The modem is an external hardware modem on a RS232 port with DE9 connector. To get that I used an old computer that's really too slow for W2K or any of the later versions. I have Windows 98 on it.

The phonesim has a DIP switch on the front, that instructions claim may increase the speed. It made no difference.
mlloyd is offline  
post #55 of 63 Old 08-09-2015, 10:12 PM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by cap_ncrunch View Post
The update from Schedules Direct was failing this morning, but it works now.

Apparently they were performing some upgrades...


Quote:
Originally Posted by cap_ncrunch View Post
I located dialupUnitDelay in the registry and modified it to my previous 24 minutes. Then, I deleted my "fake" machines. If I decide to change the spacing, I need to verify that the all machines have updated their call-in times to the new spacing before the next day's round of call-ins. Otherwise, an "old" call-in time might overlap a "new" one.

Obviously they are going to dial in today at their programmed time from yesterday, but you should see in the WiRNS log what time they are being programmed for tomorrow, and with setting dialupUnitDelay to 24 and deleted the two "fake" machines, you should see them being programmed for the exact same time as they were yesterday...

Quote:
Originally Posted by cap_ncrunch View Post
The Showstopper clocks are correct. My time zone in WiRNS shows as Pacific (correct) and time zone string as PST8PDT,M3.2.0,M11.1.0. I am assuming that the last part of the string defines the month, week and day of the week (0 = Sunday) when DST begins and ends and can be changed if Congress and the President tinker with it again.

Yes, that is a standard TZ string, which you can lookup, and you have surmised correctly the components of it...

Quote:
Originally Posted by cap_ncrunch View Post
As for mlloyd's question about the baud rate, you can shut down your virtual machine and connect to your modem with hyper terminal. Have a Replay machine make a net connect from 243-Zones. Answer the call using the modem command ATA. Once the modems complete their handshake (synchronization), you may get CONNECT followed by the baud rate. Unfortunately, for me, the rate was for the COM port (more than 115,000 bps) and not the line. There may be a way to get the modem to report the line rate instead. That would take some delving into the AT command set.
You can look at the Freesco log to see the connection information. The only thing I was very disappointed with is that it squelches the password information. But, you should be able to see everything else about the actual "live" connection to Freesco...


Henry
hdonzis is offline  
post #56 of 63 Old 08-10-2015, 10:21 AM
Member
 
cap_ncrunch's Avatar
 
Join Date: Jun 2011
Posts: 82
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 12
Mark, you could try the same experiment with the phone simulator bypassed, and see what baud rate gets returned by the CONNECT message. You already did it correctly, but for other users' benefit, the procedure is here: http://wiki.xmltv.org/index.php/ReplayTV-FREESCO If it is already running, shut down the FreeSCO virtual machine and follow the instructions that precede "Set up the FREESCO virtual machine." However, even if the rate is higher, I'd suggest staying with the simulator. Aside from the wear and tear on the external modem's relay, I believe there are some problems with the connect sequence when the Replay's attempt to connect takes place in the interval where the modem has already been sent the answer command. One possibility is that the modem may get sent the hang up command before the handshake has completed, since the modem doesn't tell the virtual machine that anything is taking place until the handshake completes and it sends CONNECT. You would lose the call, and, unless you manually do a net connect, the Replay would have to wait until the next scheduled net connect to try again.

The negative effects might be alleviated by adjusting the value of DELAY2 in mgetty, which may have to be optimized for the particular modem in use. However, I believe the fastest modems start out trying to connect at the highest baud rate, then, to support earlier vintage modems that don't support the highest rate, try to negotiate a lower rate. Remember that, when the 56K modems were introduced, the vast majority of modems in use were only capable of top speeds of 300, 1200, 2400, 9600, etc. and the new 56K modems had to be compatible with them. For that matter, I think FAX machines are locked in at 9600, and computers do communicate with FAX machines. So, if the Replay connects while the computer's modem has failed at the higher rates and is negotiating to handshake at a lower rate, you may get connected at the lower rate. So, bottom line, stay with your phone simulator, even if you can get a higher speed by bypassing it!

Possible bug: After this morning's guide updates, the 4 GetNextCall times are spaced 16 minutes apart (:00, :16, :32, and :48). However, dialupUnitDelay still has an unchanged value of 24. Yesterday, the spacing was 24 minutes after WiRNS was updated, the fake machines were removed, dialupUnitDelay was modified and, last, the Replays updated their guides.

The WiRNS log shows the Replays making their calls about 6 minutes after their scheduled times.The Replay clocks are correct, so this appears to be something built into the Replay machines' software. It is not a problem as long as all machines delay the same amount.
cap_ncrunch is offline  
post #57 of 63 Old 08-10-2015, 10:58 AM
Senior Member
 
mlloyd's Avatar
 
Join Date: Feb 2002
Location: east Texas
Posts: 353
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 51 Post(s)
Liked: 19
Quote:
Originally Posted by hdonzis View Post
You can look at the Freesco log to see the connection information. The only thing I was very disappointed with is that it squelches the password information. But, you should be able to see everything else about the actual "live" connection to Freesco...


Henry
The FREESCO instructions I had said the log wound be in /var/log/messages

It seems to contain nothing like the connect string. The first few lines after I stare the connection looks like this (each line starts with date/time):

kernel: registered device ppp0
pppd[1757]: pppd 2.3.11 started by root, uid 0
pppd[1757]: Using interface ppp0
pppd[1757]: Connect: ppp0 <--> /dev/cua0
pppd[1757]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xeae44c> <pcomp> <accomp>]
pppd[1757]: Timeout 0x8050200:0x8073550 in 3 seconds
pppd[1757]: rcvd [LCP ConfReq id=0x91 <asyncmap 0x0> <pcomp> <accomp>]

There was a lot more like this, and finally it got to some ethernet related stuff. Nothing about modem connect speed or data received. Perhaps there is a different log file somewhere (I looked at everything in /var/log and there was nothing helpful).

I remembered that I am using an old version of FREESCO (3.2) which was recommended by the instructions. Would a later version help?

Last edited by mlloyd; 08-10-2015 at 11:16 AM. Reason: additional info
mlloyd is offline  
post #58 of 63 Old 08-10-2015, 12:16 PM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by mlloyd View Post
The FREESCO instructions I had said the log wound be in /var/log/messages

It seems to contain nothing like the connect string. The first few lines after I stare the connection looks like this (each line starts with date/time):

kernel: registered device ppp0
pppd[1757]: pppd 2.3.11 started by root, uid 0
pppd[1757]: Using interface ppp0
pppd[1757]: Connect: ppp0 <--> /dev/cua0
pppd[1757]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xeae44c> <pcomp> <accomp>]
pppd[1757]: Timeout 0x8050200:0x8073550 in 3 seconds
pppd[1757]: rcvd [LCP ConfReq id=0x91 <asyncmap 0x0> <pcomp> <accomp>]

There was a lot more like this, and finally it got to some ethernet related stuff. Nothing about modem connect speed or data received. Perhaps there is a different log file somewhere (I looked at everything in /var/log and there was nothing helpful).
Since I am intimately familiar with Unix, I had no problem finding the information on the connection itself, but that was many years ago, so I'd have to dig around on the laptop again just to try and find it. I thought I had Telnet turned on, but I can't Telnet to it right now to look at anything, so I'd have to dig around on it at home some time when I have a chance. But, I suggest you look for either a serial log or a tty log...

Your PPP log doesn't look familiar to me, so maybe you are running a different version that I am. I remember distinctly it showing the login information, but it squelched the password. I don't see that in your log above...

Quote:
Originally Posted by mlloyd View Post
I remembered that I am using an old version of FREESCO (3.2) which was recommended by the instructions. Would a later version help?
I played with using a newer version, but ultimately went back to the documented version. I wrote some of my experiences with the newer version here: http://www.planetreplay.com/phpBB2/v...?p=73114#73114...

Henry
hdonzis is offline  
post #59 of 63 Old 08-10-2015, 12:40 PM
AVS Forum Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,050
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 20
Quote:
Originally Posted by cap_ncrunch View Post
Possible bug: After this morning's guide updates, the 4 GetNextCall times are spaced 16 minutes apart (:00, :16, :32, and :48). However, dialupUnitDelay still has an unchanged value of 24. Yesterday, the spacing was 24 minutes after WiRNS was updated, the fake machines were removed, dialupUnitDelay was modified and, last, the Replays updated their guides.
I think I was parsing the value incorrectly. I have posted another update...

Quote:
Originally Posted by cap_ncrunch View Post
The WiRNS log shows the Replays making their calls about 6 minutes after their scheduled times.The Replay clocks are correct, so this appears to be something built into the Replay machines' software. It is not a problem as long as all machines delay the same amount.
The GetNextCall protocol, documented here: http://www.wirns.com/twiki/RnsNextCall is totally designed around dial up. Part of the response, beside the time to call in next, is how much leeway there is on that time. You'll notice that your WiRNS log says the next call in time with how many minutes of leeway:
Code:
[8/10/2015 04:48:29] [PLUGIN] GetNextCall Time: 04:44 for 12 min to 1.2.3.5.
Where the unit will call in at 4:44AM with 12 minutes of leeway. So, your units calling 6 minutes after the time is hitting right in the middle. And, you can see from the GetNextCall documentation that there is weighting for the leeway period as well, so they must have really thought about this a lot, how to make sure and mix up when these dial-up calls happen!

Henry
hdonzis is offline  
post #60 of 63 Old 08-10-2015, 12:52 PM
Senior Member
 
mlloyd's Avatar
 
Join Date: Feb 2002
Location: east Texas
Posts: 353
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 51 Post(s)
Liked: 19
Quote:
Originally Posted by hdonzis View Post
Since I am intimately familiar with Unix, I had no problem finding the information on the connection itself, but that was many years ago, so I'd have to dig around on the laptop again just to try and find it. I thought I had Telnet turned on, but I can't Telnet to it right now to look at anything, so I'd have to dig around on it at home some time when I have a chance. But, I suggest you look for either a serial log or a tty log...

Your PPP log doesn't look familiar to me, so maybe you are running a different version that I am. I remember distinctly it showing the login information, but it squelched the password. I don't see that in your log above...



I played with using a newer version, but ultimately went back to the documented version. I wrote some of my experiences with the newer version here: http://www.planetreplay.com/phpBB2/v...?p=73114#73114...

Henry
I don't know about any "other versions" and I have checked every file in var/log . Since this actually works I would rather not worry about it now.

BTW, WiRNS looks a lot better now that I can order the Replays the way I want to.
mlloyd is offline  
Sponsored Links
Advertisement
 
Reply ReplayTV & Showstopper PVRs

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off