Hp-1 updating

[QwKiE]

How do you save the avoids list you have, before you update so you don't have to redo them everytime you update. is there a way to do this on the homepatrol 1.

 

[rwier]

How do you save the avoids list you have, before you update so you don't have to redo them everytime you update. is there a way to do this on the homepatrol 1.

I think the reason no one is rushing in with the answer is that the question might be a little confusing.

A search of the Sentinal software "help" option returns no instance of "avoid list". I use Arc Patrol Software (designed for the HP-1) and it has an extensive PDF user's manual. A search of that PDF user's manual also returns no instances of "avoid list".

Also I believe the term "update" can refer to both the "HP-1 Main Database" and the Sentinal Software. There could be a combination of many problems concerning the construction of your question.

 

[QwKiE]

updating HP !

Its not hard I have a list on my homepatrol 1, I have made the list it is an avoid list of frequencies I dont want to hear, when I update HP1 this list gos away and I have to redo it everytime as im close to Canada I get many of there frequencies I dont want to listen to Canada so I have to put them on avoid. If im updating can that list be saved so I dont have to make it everytime I update firmware or just HPDB I lose that information everytime I update. There has to be a way or maybeUniden will fix this problem if there is no fix right now.

 

[UPMan]

Before updating the database, do a "Read from HomePatrol." This will write your avoids into Sentinel and (under most circumstances) keep your avoids when up update the database.

 

[b52hbuff]

Before updating the database, do a "Read from HomePatrol." This will write your avoids into Sentinel and (under most circumstances) keep your avoids when up update the database.

Interesting. I always use temporary lockouts, so I never knew how this worked.

...so if the 'technology' exists to preserve avoids, why not incorporate similar functions/algorithms to update Favorites list? I can understand why you wouldn't do it automagically, but at least offer the user to interact with Sentinal to resolve the conflicts.

 

[UPMan]

Aside from the programmatic problems, what should be done if you have changed an alpha tag (it won't match the main dB...so it would look "updated" to Sentinel). Or, what if the tag is updated both in RRDB and in Sentinel; which one should be used?

Now, add in that Favorites Lists can be made using 3rd party software, so there may be channels in the FL that aren't in (and were never in) the Main DB...Should they be deleted from the FL? (From Sentinel's POV, it would appear that they had once been in the Main DB but were then deleted from there...which is a valid condition.)

What if a TGID for a channel changes...how should Sentinel determine that it is still the "Same Channel"...base it on the Alpha Tag? But, it isn't unusual for there to be multiple channels in a system with the same alpha tag...

There are just so many "what ifs" and "possible if not probable" exceptions, it just really isn't feasible to try to "sync" favorites lists with the Main dB...it is more likely that such a process would break things (from the user's perspective) as often as not.

Keeping the Avoid in the Main dB is simpler (but there are still exceptions...for example, if a channel's TGID changes, the avoid will probably be lost from the Main dB). And, the ramifications of a bad "sync" for avoids is just that you need to re-avoid the channel...much less than a bad sync on Favorites Lists.

 

[jkahn]

Paul:

That explanation makes sense.
Unless I am mistaken, when I added (ie) Montgomery County's TRS into a favorites list, I avoided all of the "groupings" of TGIDs that I didn't want to hear, such as schools and highway & Traffic that are in the system. I later created another favorites list for another purpose, and again loaded Montgomery's TRS from the database. When I went to avoid the same groupings, I found they were already avoided, which tells me that changes to a system, made while in a favorites list, are also replicated in the main database file for that system.

What your explanation tells me is that the reverse is not true. If the system is updated in the main database, the groupings or TGIDs that had been avoided and that changed with the update, will not be updated in the favorites list copy of that system. Is that correct?

JK

 

[UPMan]

I don't believe that Avoids in a FL are reflected in the Main dB...but I'd have to do some checking to verify and have an overflowing plateful of things on my todo list with higher priorities at the moment.