Database Updates do NOT update Favs Lists!

[dfw1417]

I read this somewhere the other day and just thought WOW what a way to run a railroad!

I can update the master database using Sentenial but all those favorites lists (up to 256) which I had previously created with a now
changed database or system information will NOT AUTOMATICALLY UPDATE!!

What this means is I have to Manually update by remvoing and again appending systems to each and every favorites list I had previously created with the old outdated database information!

This may explain why a lot of folks are waking up one morning and not hearing the systems they used to hear just fine! IF the system has changed and the database was updated even if you keep your database always current, unless you re-create your favorites lists which include systems that have changed data you will NEVER hear them again!

I am beginning to understand why so many are posting saying I cant hear my system anymore.

Of course the Sentennial manual doesnt say a word about this issue either.

Hmmm....

There outta be a better way!

 

[UPMan]

If we did update all the Favorites Lists when channels in the FL didn't match the main dB, that would really tick off people who had spent a lot of time and effort in setting their own alpha tags, different location settings, etc. There is no way to:

a) Know that a channel in the main dB has changed since last time you updated Sentinel; or,
b) Know that the reason a channel in the main dB does not match a channel in a FL was due to a change at RadioReference or a change the user made; or,
c) Know that the reason a channel seems missing from the main dB but is in the FL is because the user manually added it to the FL; or,
d) Know that the reason a channel is not in an FL but is in the Main dB is because the user doesn't want that channel in their FL; or...

Basically, there are so many different decision tree items that are totally dependent on what the user has or has not done, matching things up becomes impossible.

 

[SCPD]

And I'm glad. My favorites lists are much modified from the USA full database. If changes occur that would affect stuff in the favorites I just manually modify/edit them. Not a big deal. Usually not much changes anyway.

```
slow typist...

 

[dfw1417]

I agree with you it would be challenging.

I think this information would be a great help if it was provided or explained in the Sentinnel manual, I may have missed it but I dont recall even realizing this until I read it the other day even though I have had the Home Patrol for over a year and just got the BCD436HP yesterday.

Now I know what to look for and when I import my Home Patrol favorites to the BCD436 I will know to update them with the current database.

Thanks Paul you have done a great job with the BCD436HP.

 

[ofd8001]

It would be a very nice thing to have a "date changed" field/column in the database. That way one could have an idea of whether a change/addition to a specific item is recent, thus warranting a change in a Favorites List.

 

[DSC45]

ofd8001, That's a great idea!

 

[jdolina]

I didn't want to start complaining but it really is a pain to have to update something which should update itself. This is the ONE thing I HATE about the new scanners. This does not seem like rocket science to solve having done many programming software projects.

You really have two types of updates conventional and trunk

You have a profile setting 'conventional update alpha tags yes/no' really all most people care about is the frequency and tone when a change occurs but give them a choice.

Trunk systems add an extra option to ask to update talkgroups alpha tag and one to add/remove SITES

Maybe an option to not update anything but give the user the choice

Now on to the we cant do this part from Uniden

a) Know that a channel in the main dB has changed since last time you updated Sentinel; or,

Dont need to know but you could add a date. You already tag each object with an ID just look for ID's in FL that match is the pertinent information different? frequency, tone, talk group ID then UPDATE

ID's that are not in the FL add
ID's in the FL not in the DB delete


b) Know that the reason a channel in the main dB does not match a channel in a FL was due to a change at RadioReference or a change the user made; or,

Again choices in the profile most people are just looking for the majore parts to be updated. Don't need to mess with all the other fields and ask for tags.

c) Know that the reason a channel seems missing from the main dB but is in the FL is because the user manually added it to the FL; or,

If they manually add it then no matching ID seems logical so again leave it alone


d) Know that the reason a channel is not in an FL but is in the Main dB is because the user doesn't want that channel in their FL; or...

Trying hard to think of why this would be unless someone wasnt using location correctly or lockout.
But again maybe you just have to prompt for each one and ask do you want to add this?

It really is worse to have to either delete and remake the whole FL (resetting color timeout priority for all) to get things like departments/site updates or have to put changes in manually and figure out what changed. Since I cant run two versions of the software to match it up that way I had to create a virtual machine to run a scratch copy. I load the windows side by side. Pull up the master DB on scratch and FL on the other. Then match and change. This usually takes about 30 minutes to hours depending on the amount of changes two times a week.

 

[dmg1969]

The easy way I know what needs to be updated is to check my RR home page each day. I have "My Counties" and My Trunked Systems". If a system has been updated, I can go in to see why and if I need to update a site, TGID, etc.

 

[troymail]

I agree it would be hard for conventional but for trunked systems, as long as the database default names for the system and sites are in place, the software could at least do a compare of the database vs. the programmed data/scan lists and prompt the user for differences:

Upon running the database download....

User, would you like to check for changes in this update?

Upon encountering a site with different frequencies, prompt the user:

Site frequency XXX.XX appears to be new - would you like to add it?

Upon encountering new talkgroups for the system, ask the user:

Would you like to add this new talkgroup?

Of course - always give the user the option to abort the process.

Most systems aren't going to change that match so the process shouldn't take too long and/or find that much from week to week.

It can be done --

EDIT: At a minimum, it would be nice to have the software present the user with a "diff list" (show what has changed) between library versions and/or between the library and their programming....

 

[phask]

Same old question, same old answers - jeez guys - take a little time and search. This has been debated, digested, and thrown up since the HP1.

Same thing pops up about every 6 weeks.

 

[troymail]

Same old question, same old answers - jeez guys - take a little time and search. This has been debated, digested, and thrown up since the HP1.

Same thing pops up about every 6 weeks.

Sure - but it's still good to hear what the customers want (not just the first person who mentions it so vendors can say 'well, we only got one request for that").

 

[detroit780]

Update Favorites

You can copy the updated trunked system over your current favorite list. However if you like to rename the channels so you know what they actually are it will add them again under the RR name. Then you'll have to delete all the duplicates.

It would be nice if the software looked at the system SID and TG numbers. Then if you renamed anything it would skip those and only place the new TG's into your favorites. Seems like that would be an easy add but who knows.

I agree it would be hard for conventional but for trunked systems, as long as the database default names for the system and sites are in place, the software could at least do a compare of the database vs. the programmed data/scan lists and prompt the user for differences:

Upon running the database download....

User, would you like to check for changes in this update?

Upon encountering a site with different frequencies, prompt the user:

Site frequency XXX.XX appears to be new - would you like to add it?

Upon encountering new talkgroups for the system, ask the user:

Would you like to add this new talkgroup?

Of course - always give the user the option to abort the process.

Most systems aren't going to change that match so the process shouldn't take too long and/or find that much from week to week.

It can be done --

EDIT: At a minimum, it would be nice to have the software present the user with a "diff list" (show what has changed) between library versions and/or between the library and their programming....

 

[DSC45]

Another Great Thought!

The easy way I know what needs to be updated is to check my RR home page each day. I have "My Counties" and My Trunked Systems". If a system has been updated, I can go in to see why and if I need to update a site, TGID, etc.

I check the RR site at least twice a week to see if any changes are made to my county. It is the easiest thing to do, than determined by the highlighted change if it will effect my scanning. If so, I know to change that channel.

 

[durangoGreg]

Actually this would be a piece of cake to program.

All that is needed is an option box in each favorite list that says "UPDATE yes/no".

If the user toggles "UPDATE" then that particular favorite list would be updated when the entire DB is updated.

If the user does not toggle "UPDATE" then that particular list would not be updated.

Simple! A user then could have custom favorite lists that would not be corrupted by updating along with simple favorite lists that would be changed with updating.

 

[DataSquid]

I found another dead horse it seems...

So the dream of selectively merging DB updates into my FLs is dead, but did I miss where I can review all the changes being made to the master DB during an update? Or is that not logged anywhere?

 

[ofd8001]

I found another dead horse it seems...

So the dream of selectively merging DB updates into my FLs is dead, but did I miss where I can review all the changes being made to the master DB during an update? Or is that not logged anywhere?

I've posted several requests/suggestions to add a field or two to the RR database that would show the action taken to an entry (add/change/delete) and the date that action was taken.

I know it would be a ton of work to get started, but I believe this would be a valuable update to the database.

 

[budevans]

Add/Change Notifications List

If we did update all the Favorites Lists when channels in the FL didn't match the main dB, that would really tick off people who had spent a lot of time and effort in setting their own alpha tags, different location settings, etc. There is no way to:

a) Know that a channel in the main dB has changed since last time you updated Sentinel; or,
b) Know that the reason a channel in the main dB does not match a channel in a FL was due to a change at RadioReference or a change the user made; or,
c) Know that the reason a channel seems missing from the main dB but is in the FL is because the user manually added it to the FL; or,
d) Know that the reason a channel is not in an FL but is in the Main dB is because the user doesn't want that channel in their FL; or...

Basically, there are so many different decision tree items that are totally dependent on what the user has or has not done, matching things up becomes impossible.

I spent a lot of time and thought customizing my Favorites List. I would be against automatic updates that modify my existing customizations without some form of input by me.

However what I would consider:

1. The option to get a notification (list) as to new adds/changes to my existing systems.

2. The option to allow me to accept or reject adds/changes from the notification (list) or let me print the list. So that I can make the adds/changes.

3. If I accept adds/changes then bring up the screen for each add/change to make the appropritate settings (delay, alert, service type, etc...).

I think the ability to get an adds/changes notification list in Sentinal each week would be a big plus verses my current manual method of scouring the RR databases via the website.

 

[mjs438]

Thank you. You answered my question

 

[MStep]

I'd love to once again congratulate (and again, belatedly) Paul Opitz, or Uniden, or whoever came up with the brilliant idea of the HP1 and its tie-in to the RR database. The whole HP1 concept was a stroke of genius, from its operation, to its form-factor, to its screen. Being here in "The Tavern" gives me an opportunity to get into a brief philosophical discourse to explore a bit the idea of the main database and favorites lists.

Of course I can't speak for any of the aforementioned, but I somehow get the feeling that the whole concept of the use of the database and favorites lists have evolved somewhat since the inception of the HP1.

Perhaps the original concept might have been to use the database (which is updated every week, more or less), to a greater extent for monitoring, perhaps as the main "attraction" so to speak, and to use favorites lists as something you would create on a more temporary basis, for either mobile monitoring excursions, or perhaps for armchair adventures into specific trunked systems or groups of conventional frequencies.

With the unprecedented success of the HP1 (I think that Paul commented here a few times that it is/was one of Uniden's all time, best-selling scanners), folks may have soon realized the immense potential in customizing and keeping favorites lists, and they became a more prominent and permanent feature on our scanners.

Of course, this is all just hypothetical bantering--- something that you would only find in "The Tavern", (and at this late hour), but this theory could explain why not much forethought went into a method, a system, a way, as it were, to keep favorites lists somehow tied into the main database. In the course of the evolution of the use of these scanners, the main database and the favorites lists became "split", each coming into their own, and now, as time has gone by, the reintegration of these two methods of monitoring (full vs favorites) is no longer practical or possible. Just having a little fun here, but it's food for thought.