Otter


David Oxford
 

Andy

Ryan forwarded your message to me about OTTER. I’ve been a big advocate for using and reestablishing OTTER as a tool in the OTR world. Since Jim’s death a few years ago it has not been updated. [I meant Jim at an OTR conference in Cincinnati several years ago and had exchanged a few hundred emails with him.] 

I think our not maintaining and using OTTER is a real shame. I have too many irons in the fire to want to undertake it’s maintenance myself. (We’ve acquired several thousand reels and I can run 5 reel-to-reel decks simultaneously). I’m also the Purchasing Group Moderator which means I put together the distros. I plead ignorance of any expertise using OTTER other than the few things I’ve looked up when needing an updated log for my own use. I have used it fairly extensively for renaming files. I’ve suggested we post on main@OldTimeRadioResearchers.groups.io for someone willing to manage OTTER but haven’t done so yet.

Could you tell me of your experience and expertise using OTTER? 

David Oxford
OTRR member
Moderator of the OTRR Purchasing Group


Begin forwarded message:

From: Ryan Ellett <oldradiotimes@...>
Subject: Fw: Otter
Date: February 1, 2023 at 10:48:27 CST
To: David Oxford <deojao@...>

I sent this to Joe but he reminded me that you've been the one pushing us to get Otter back up and running.
Ryand



The Old Time Radio Researchers
"Saving the Past for the Future"




----- Forwarded Message -----

From: Ryan Ellett <oldradiotimes@...>
To: Joseph Webb <drjoewebb@...>; Andrew Steinberg <nightkey5@...>
Sent: Wednesday, February 1, 2023, 09:58:08 AM CST
Subject: Otter

Joe and Andrew,
Someone named Andy just joined OTRR on .io with an interest in Otter. I don't know him (his email is rizzo-otr@... if it looks familiar). I know you both have been big advocates of Otter in the past with an interest in seeing it revitalized. This is what he wrote:

 "As i am based in the UK i found, and still find it difficult researching however i used to help our late friend Jim now and again with grammar, punctuation checking and date updates of the titles in the Otter logs. Is Otter still used? I also used to have a large library available on the hub that was easier to download for people in the UK who were members. Broadband speeds now though make the world a much smaller place.

 I followed up and would let him know how he might be able to help with Otter. I never used it so I'm not one to really speak about Otter; could he be brought up to speed on updating and maintaining it? Would Paul need to be involved? I don't even know how to access the Otter files to update and proof them.
Ryan



The Old Time Radio Researchers
"Saving the Past for the Future"




Brian Kavanaugh
 

The biggest problem is we don't have the source code for the application, so we can't update it. The text files that it uses... That would require someone to take that up. I've included otter-compatible files in the handful of maintained sets I've led.

Evan (Wild West Designs) was working on an otter-like application. I haven't seen much about it recently, but I know he's still in this group so maybe he'll comment on where that is at. If you search the group, you'll see messages about it (around August/September 2020).

https://oldtimeradioresearchers.groups.io/g/main/search?p=recentpostdate%2Fsticky%2C%2C%2C20%2C2%2C0%2C0&q=otter


Rizzo
 

Hi David,

 

I use Otter quite a lot to manage my collection and keep track of episodes I have and am missing including registering, renaming, id3 tags etc. I also know how to edit series, add new series, edit/update logs and export/import logs. It is also possible to compile a new database containing all updated logs so that it can be made available as a single download as per the database currently available on the OTRR website. I do have two installations of Otter. One that is the master database and one that is my collection where I may have made amendments.

 

For the purposes of distributing updates, I was thinking something along the lines of the following:

 

  • Using a copy of the master database (the last updated one from the OTRR website, so it is a fresh starting point that everyone is familiar with) in a separate installation, make any updates as necessary. These updates could then be compiled into a new database that could be downloaded from the OTRR website (creating a new starting point). We could make a new database available perhaps quarterly.
  • Separately, for all the updates made, make a zip file available to coincide with the database update on the OTRR website of the exported log files. This would allow researchers to review or validate the logs themselves before importing them against their installation of the Otter database. In this way they would not lose any edits they have made to any other series in their database but still get the benefit of newly updated logs. This could also include a release note of some description, detailing the updates in the database, the series affected and the source of those updates (eg old time logs, vintage logs etc).

 

I was also thinking of adding two new episode entries into each certified series (with a not exists indicator), labelled YY/xx/xx, episode 00 so they appear at the top of a series log. These entries could be OTRR Certified [Complete|Accurate|Maintained] - VerNNNN and a second entry containing the url to the location of the landing page on the internet archive. For example:

 

                21st Precinct

                53/xx/xx 0 OTRR Certificate Accurate – Ver3

                53/xx/xx 0 https://archive.org/details/OTRR_Certified_21st_Precinct

 

Let me know what you think and if I can help.

 

Andy

 

Sent from Mail for Windows

 

From: David Oxford
Sent: 02 February 2023 20:56
To: rizzo-otr@...
Cc: main@oldtimeradioresearchers.groups.io
Subject: Fwd: Otter

 

Andy

 

Ryan forwarded your message to me about OTTER. I’ve been a big advocate for using and reestablishing OTTER as a tool in the OTR world. Since Jim’s death a few years ago it has not been updated. [I meant Jim at an OTR conference in Cincinnati several years ago and had exchanged a few hundred emails with him.] 

 

I think our not maintaining and using OTTER is a real shame. I have too many irons in the fire to want to undertake it’s maintenance myself. (We’ve acquired several thousand reels and I can run 5 reel-to-reel decks simultaneously). I’m also the Purchasing Group Moderator which means I put together the distros. I plead ignorance of any expertise using OTTER other than the few things I’ve looked up when needing an updated log for my own use. I have used it fairly extensively for renaming files. I’ve suggested we post on main@OldTimeRadioResearchers.groups.io for someone willing to manage OTTER but haven’t done so yet.

 

Could you tell me of your experience and expertise using OTTER? 

 

David Oxford

OTRR member

Moderator of the OTRR Purchasing Group

 

 

Begin forwarded message:

 

From: Ryan Ellett <oldradiotimes@...>

Subject: Fw: Otter

Date: February 1, 2023 at 10:48:27 CST

To: David Oxford <deojao@...>

 

I sent this to Joe but he reminded me that you've been the one pushing us to get Otter back up and running.

Ryand

 

 

 

The Old Time Radio Researchers

"Saving the Past for the Future"

 

 

 

 

----- Forwarded Message -----

From: Ryan Ellett <oldradiotimes@...>

To: Joseph Webb <drjoewebb@...>; Andrew Steinberg <nightkey5@...>

Sent: Wednesday, February 1, 2023, 09:58:08 AM CST

Subject: Otter

 

Joe and Andrew,

Someone named Andy just joined OTRR on .io with an interest in Otter. I don't know him (his email is rizzo-otr@... if it looks familiar). I know you both have been big advocates of Otter in the past with an interest in seeing it revitalized. This is what he wrote:

 

 "As i am based in the UK i found, and still find it difficult researching however i used to help our late friend Jim now and again with grammar, punctuation checking and date updates of the titles in the Otter logs. Is Otter still used? I also used to have a large library available on the hub that was easier to download for people in the UK who were members. Broadband speeds now though make the world a much smaller place.

 

 I followed up and would let him know how he might be able to help with Otter. I never used it so I'm not one to really speak about Otter; could he be brought up to speed on updating and maintaining it? Would Paul need to be involved? I don't even know how to access the Otter files to update and proof them.

Ryan

 

 

 

The Old Time Radio Researchers

"Saving the Past for the Future"

 

 

 

 


Michael Hingson
 

And for some of us newer to this list, what please is Otter? Thanks.

 

 

Best Regards,

 

 

Michael Hingson

 

 

From: main@OldTimeRadioResearchers.groups.io <main@OldTimeRadioResearchers.groups.io> On Behalf Of Rizzo via groups.io
Sent: Friday, February 3, 2023 5:00 AM
To: David Oxford <deojao@...>
Cc: main@oldtimeradioresearchers.groups.io
Subject: Re: [OldTimeRadioResearchers] Otter

 

Hi David,

 

I use Otter quite a lot to manage my collection and keep track of episodes I have and am missing including registering, renaming, id3 tags etc. I also know how to edit series, add new series, edit/update logs and export/import logs. It is also possible to compile a new database containing all updated logs so that it can be made available as a single download as per the database currently available on the OTRR website. I do have two installations of Otter. One that is the master database and one that is my collection where I may have made amendments.

 

For the purposes of distributing updates, I was thinking something along the lines of the following:

 

  • Using a copy of the master database (the last updated one from the OTRR website, so it is a fresh starting point that everyone is familiar with) in a separate installation, make any updates as necessary. These updates could then be compiled into a new database that could be downloaded from the OTRR website (creating a new starting point). We could make a new database available perhaps quarterly.
  • Separately, for all the updates made, make a zip file available to coincide with the database update on the OTRR website of the exported log files. This would allow researchers to review or validate the logs themselves before importing them against their installation of the Otter database. In this way they would not lose any edits they have made to any other series in their database but still get the benefit of newly updated logs. This could also include a release note of some description, detailing the updates in the database, the series affected and the source of those updates (eg old time logs, vintage logs etc).

 

I was also thinking of adding two new episode entries into each certified series (with a not exists indicator), labelled YY/xx/xx, episode 00 so they appear at the top of a series log. These entries could be OTRR Certified [Complete|Accurate|Maintained] - VerNNNN and a second entry containing the url to the location of the landing page on the internet archive. For example:

 

                21st Precinct

                53/xx/xx 0 OTRR Certificate Accurate – Ver3

                53/xx/xx 0 https://archive.org/details/OTRR_Certified_21st_Precinct

 

Let me know what you think and if I can help.

 

Andy

 

Sent from Mail for Windows

 

From: David Oxford
Sent: 02 February 2023 20:56
To: rizzo-otr@...
Cc: main@oldtimeradioresearchers.groups.io
Subject: Fwd: Otter

 

Andy

 

Ryan forwarded your message to me about OTTER. I’ve been a big advocate for using and reestablishing OTTER as a tool in the OTR world. Since Jim’s death a few years ago it has not been updated. [I meant Jim at an OTR conference in Cincinnati several years ago and had exchanged a few hundred emails with him.] 

 

I think our not maintaining and using OTTER is a real shame. I have too many irons in the fire to want to undertake it’s maintenance myself. (We’ve acquired several thousand reels and I can run 5 reel-to-reel decks simultaneously). I’m also the Purchasing Group Moderator which means I put together the distros. I plead ignorance of any expertise using OTTER other than the few things I’ve looked up when needing an updated log for my own use. I have used it fairly extensively for renaming files. I’ve suggested we post on main@OldTimeRadioResearchers.groups.io for someone willing to manage OTTER but haven’t done so yet.

 

Could you tell me of your experience and expertise using OTTER? 

 

David Oxford

OTRR member

Moderator of the OTRR Purchasing Group

 

 

Begin forwarded message:

 

From: Ryan Ellett <oldradiotimes@...>

Subject: Fw: Otter

Date: February 1, 2023 at 10:48:27 CST

To: David Oxford <deojao@...>

 

I sent this to Joe but he reminded me that you've been the one pushing us to get Otter back up and running.

Ryand

 

 

 

The Old Time Radio Researchers

"Saving the Past for the Future"

 

 

 

 

----- Forwarded Message -----

From: Ryan Ellett <oldradiotimes@...>

To: Joseph Webb <drjoewebb@...>; Andrew Steinberg <nightkey5@...>

Sent: Wednesday, February 1, 2023, 09:58:08 AM CST

Subject: Otter

 

Joe and Andrew,

Someone named Andy just joined OTRR on .io with an interest in Otter. I don't know him (his email is rizzo-otr@... if it looks familiar). I know you both have been big advocates of Otter in the past with an interest in seeing it revitalized. This is what he wrote:

 

 "As i am based in the UK i found, and still find it difficult researching however i used to help our late friend Jim now and again with grammar, punctuation checking and date updates of the titles in the Otter logs. Is Otter still used? I also used to have a large library available on the hub that was easier to download for people in the UK who were members. Broadband speeds now though make the world a much smaller place.

 

 I followed up and would let him know how he might be able to help with Otter. I never used it so I'm not one to really speak about Otter; could he be brought up to speed on updating and maintaining it? Would Paul need to be involved? I don't even know how to access the Otter files to update and proof them.

Ryan

 

 

 

The Old Time Radio Researchers

"Saving the Past for the Future"

 

 

 

 


Wild West Designs
 

Big fan of Otter here.  Unfortunately, it is 32 bit, so that does present it with a limited life span.

I have been working on a version.  I'm trying to decide on the best way forward.  I have written a version in Go,  Python and in GDScript (I may stick with this one as it would be the easiest SDK for anyone else to download and start contributing, I just need to retool the code a bit, could also use CPP with it (already do for the sqlite portion), so there are more options with the game engine versus the others).  All versions are cross platform.  Go uses Fyne, OpenGL (which has lifespan issues), the python uses TK for it's UI.  Not bad, but it is an older looking UI.  GDScript uses the Godot engine, while the stable version still uses OpenGL, when Godot 4.0 releases, it should be using Vulkan.  I did have a version using C++ and Qt, but that would be massive for others to contribute to, so I decided to stick with the others.

My goal was to have it as cross platform as it can be and it will be open source as well, so anyone could submit changes as well on Gitlab (that's where I plan to host it).  I did update some of the Otter database, but it is based on the original Otter database for the most part.

Any thoughts, ideas, suggestions, let me know while in the refactoring stages and I'll let the group know when I have it on Gitlab.

Evan 


Jim Wood
 

A big thank you Even for doing this. Really looking forward to seeing what you come up with.

 

Jim

 

From: main@OldTimeRadioResearchers.groups.io <main@OldTimeRadioResearchers.groups.io> On Behalf Of Wild West Designs
Sent: Monday, February 6, 2023 6:35 PM
To: main@OldTimeRadioResearchers.groups.io
Subject: Re: [OldTimeRadioResearchers] Otter

 

Big fan of Otter here.  Unfortunately, it is 32 bit, so that does present it with a limited life span.

I have been working on a version.  I'm trying to decide on the best way forward.  I have written a version in Go,  Python and in GDScript (I may stick with this one as it would be the easiest SDK for anyone else to download and start contributing, I just need to retool the code a bit, could also use CPP with it (already do for the sqlite portion), so there are more options with the game engine versus the others).  All versions are cross platform.  Go uses Fyne, OpenGL (which has lifespan issues), the python uses TK for it's UI.  Not bad, but it is an older looking UI.  GDScript uses the Godot engine, while the stable version still uses OpenGL, when Godot 4.0 releases, it should be using Vulkan.  I did have a version using C++ and Qt, but that would be massive for others to contribute to, so I decided to stick with the others.

My goal was to have it as cross platform as it can be and it will be open source as well, so anyone could submit changes as well on Gitlab (that's where I plan to host it).  I did update some of the Otter database, but it is based on the original Otter database for the most part.

Any thoughts, ideas, suggestions, let me know while in the refactoring stages and I'll let the group know when I have it on Gitlab.

Evan 


Bill Clough
 

I guess that a version of SQL is out of the question.
It seems that SQL could bring things up to date.

Bill

On 2/6/2023 6:35 PM, Wild West Designs wrote:

Big fan of Otter here.  Unfortunately, it is 32 bit, so that does present it with a limited life span.

I have been working on a version.  I'm trying to decide on the best way forward.  I have written a version in Go,  Python and in GDScript (I may stick with this one as it would be the easiest SDK for anyone else to download and start contributing, I just need to retool the code a bit, could also use CPP with it (already do for the sqlite portion), so there are more options with the game engine versus the others).  All versions are cross platform.  Go uses Fyne, OpenGL (which has lifespan issues), the python uses TK for it's UI.  Not bad, but it is an older looking UI.  GDScript uses the Godot engine, while the stable version still uses OpenGL, when Godot 4.0 releases, it should be using Vulkan.  I did have a version using C++ and Qt, but that would be massive for others to contribute to, so I decided to stick with the others.

My goal was to have it as cross platform as it can be and it will be open source as well, so anyone could submit changes as well on Gitlab (that's where I plan to host it).  I did update some of the Otter database, but it is based on the original Otter database for the most part.

Any thoughts, ideas, suggestions, let me know while in the refactoring stages and I'll let the group know when I have it on Gitlab.

Evan 


Wild West Designs
 

To me, the benefits of using SQL versus SQLite are very, very small considering this isn't a web app dealing with many, many concurrent queries or being used even within a LAN and getting all of those queries at the same time, compared to the overhead of getting SQL up and running versus SQLite.  SQLite database would also make it easier to work with C++, Nim, Python, Go without really needing to make changes to the database that I already have, if it needs to be ported to something else (really the only thing that got me switching from language to language was UI frameworks and licenses there of, especially for desktop UI).  I think SQL was used in the original database as I had to export all the database to .txt files (it wouldn't read directly using SQLite and it has really good backwards compatibility, so I don't think it was just do to an older version of SQLite), from there turn those into .csv files with proper formatting and push those into the new database (it took me a while to make the python script to do that, but thankfully that was done, otherwise I don't know if I would have been able to do the program otherwise without starting from scratch).


I'll see about getting some screenshots.  I will be refactoring the UI and the theming (it uses Godot's default theme, so I don't think that is the best thing).  Right now, since I have been the only one using it, it does the usual database operations (retrieve, delete, get master list, add episode, delete episode).  I do eventually want to add in export CSV and Import CSV.  Goal would be to have it easier for many people to be working on different logs and really on the individual CSV is needed to be pushed to the repo etc.  I do have a note taking portion as well.  Not a fully fledged out text editor, but the options are there, just need to code it in there (syntax highlighting, finding etc) if that is a desired feature.

The one thing that I have toyed with, is if there is an interest in FFMPEG/FFPLAY integration to have stations preprogrammed in there (say Bygolly OTR, Audio Noir etc) and be able to play those as well.  I don't know if there is an interest for that as well.  Let me know.  It would require that ffmpeg is installed and on PATH to work, but if one is dealing with audio manipulation at all, FFMPEG is a worthy suite of tools to have anyway.


Evan

On 2023-02-06 07:31 PM, Bill Clough via groups.io wrote:

I guess that a version of SQL is out of the question.
It seems that SQL could bring things up to date.

Bill

On 2/6/2023 6:35 PM, Wild West Designs wrote:
Big fan of Otter here.  Unfortunately, it is 32 bit, so that does present it with a limited life span.

I have been working on a version.  I'm trying to decide on the best way forward.  I have written a version in Go,  Python and in GDScript (I may stick with this one as it would be the easiest SDK for anyone else to download and start contributing, I just need to retool the code a bit, could also use CPP with it (already do for the sqlite portion), so there are more options with the game engine versus the others).  All versions are cross platform.  Go uses Fyne, OpenGL (which has lifespan issues), the python uses TK for it's UI.  Not bad, but it is an older looking UI.  GDScript uses the Godot engine, while the stable version still uses OpenGL, when Godot 4.0 releases, it should be using Vulkan.  I did have a version using C++ and Qt, but that would be massive for others to contribute to, so I decided to stick with the others.

My goal was to have it as cross platform as it can be and it will be open source as well, so anyone could submit changes as well on Gitlab (that's where I plan to host it).  I did update some of the Otter database, but it is based on the original Otter database for the most part.

Any thoughts, ideas, suggestions, let me know while in the refactoring stages and I'll let the group know when I have it on Gitlab.

Evan 


Edward A. (Ted) Jones
 

If we do Otter-driven file mgmt/renaming (local file changes), please make it forgiving, aka temp files that can be manually managed.


On Mon, Feb 6, 2023 at 8:53 PM, Wild West Designs
<evan@...> wrote:

To me, the benefits of using SQL versus SQLite are very, very small considering this isn't a web app dealing with many, many concurrent queries or being used even within a LAN and getting all of those queries at the same time, compared to the overhead of getting SQL up and running versus SQLite.  SQLite database would also make it easier to work with C++, Nim, Python, Go without really needing to make changes to the database that I already have, if it needs to be ported to something else (really the only thing that got me switching from language to language was UI frameworks and licenses there of, especially for desktop UI).  I think SQL was used in the original database as I had to export all the database to .txt files (it wouldn't read directly using SQLite and it has really good backwards compatibility, so I don't think it was just do to an older version of SQLite), from there turn those into .csv files with proper formatting and push those into the new database (it took me a while to make the python script to do that, but thankfully that was done, otherwise I don't know if I would have been able to do the program otherwise without starting from scratch).


I'll see about getting some screenshots.  I will be refactoring the UI and the theming (it uses Godot's default theme, so I don't think that is the best thing).  Right now, since I have been the only one using it, it does the usual database operations (retrieve, delete, get master list, add episode, delete episode).  I do eventually want to add in export CSV and Import CSV.  Goal would be to have it easier for many people to be working on different logs and really on the individual CSV is needed to be pushed to the repo etc.  I do have a note taking portion as well.  Not a fully fledged out text editor, but the options are there, just need to code it in there (syntax highlighting, finding etc) if that is a desired feature.

The one thing that I have toyed with, is if there is an interest in FFMPEG/FFPLAY integration to have stations preprogrammed in there (say Bygolly OTR, Audio Noir etc) and be able to play those as well.  I don't know if there is an interest for that as well.  Let me know.  It would require that ffmpeg is installed and on PATH to work, but if one is dealing with audio manipulation at all, FFMPEG is a worthy suite of tools to have anyway.


Evan

On 2023-02-06 07:31 PM, Bill Clough via groups.io wrote:

I guess that a version of SQL is out of the question.
It seems that SQL could bring things up to date.

Bill

On 2/6/2023 6:35 PM, Wild West Designs wrote:
Big fan of Otter here.  Unfortunately, it is 32 bit, so that does present it with a limited life span.

I have been working on a version.  I'm trying to decide on the best way forward.  I have written a version in Go,  Python and in GDScript (I may stick with this one as it would be the easiest SDK for anyone else to download and start contributing, I just need to retool the code a bit, could also use CPP with it (already do for the sqlite portion), so there are more options with the game engine versus the others).  All versions are cross platform.  Go uses Fyne, OpenGL (which has lifespan issues), the python uses TK for it's UI.  Not bad, but it is an older looking UI.  GDScript uses the Godot engine, while the stable version still uses OpenGL, when Godot 4.0 releases, it should be using Vulkan.  I did have a version using C++ and Qt, but that would be massive for others to contribute to, so I decided to stick with the others.

My goal was to have it as cross platform as it can be and it will be open source as well, so anyone could submit changes as well on Gitlab (that's where I plan to host it).  I did update some of the Otter database, but it is based on the original Otter database for the most part.

Any thoughts, ideas, suggestions, let me know while in the refactoring stages and I'll let the group know when I have it on Gitlab.

Evan 


Wild West Designs
 

That I do not plan on having, unless someone wants to help with that.  Mainly for the reason you state, it wasn't forgiving.  It was very opinionated and even as a frequent Otter user, I hardly used it, because it was opinionated in a way that I didn't use.  Also doing something cross platform (I mainly run on Linux for instance) how directories/files are formatted are also different, so that would add another wrench in that plan.  Not to say that it couldn't be solved, but if the language doesn't have a means to address it (and even if the language does, sometimes it's a booger to set up), it's hard to handle.

It's a nice idea, but as of now, I don't plan on supporting it, unless I either find an easy way to handle it or someone more knowledgeable is able to take that forward (one of the reasons why I plan to open source it as well, even if I am unable to do it, someone else might and it would still be able to be made better.


Evan


On 2023-02-06 08:23 PM, Edward A. (Ted) Jones via groups.io wrote:

If we do Otter-driven file mgmt/renaming (local file changes), please make it forgiving, aka temp files that can be manually managed.

 

On Mon, Feb 6, 2023 at 8:53 PM, Wild West Designs
<evan@...> wrote:

To me, the benefits of using SQL versus SQLite are very, very small considering this isn't a web app dealing with many, many concurrent queries or being used even within a LAN and getting all of those queries at the same time, compared to the overhead of getting SQL up and running versus SQLite.  SQLite database would also make it easier to work with C++, Nim, Python, Go without really needing to make changes to the database that I already have, if it needs to be ported to something else (really the only thing that got me switching from language to language was UI frameworks and licenses there of, especially for desktop UI).  I think SQL was used in the original database as I had to export all the database to .txt files (it wouldn't read directly using SQLite and it has really good backwards compatibility, so I don't think it was just do to an older version of SQLite), from there turn those into .csv files with proper formatting and push those into the new database (it took me a while to make the python script to do that, but thankfully that was done, otherwise I don't know if I would have been able to do the program otherwise without starting from scratch).


I'll see about getting some screenshots.  I will be refactoring the UI and the theming (it uses Godot's default theme, so I don't think that is the best thing).  Right now, since I have been the only one using it, it does the usual database operations (retrieve, delete, get master list, add episode, delete episode).  I do eventually want to add in export CSV and Import CSV.  Goal would be to have it easier for many people to be working on different logs and really on the individual CSV is needed to be pushed to the repo etc.  I do have a note taking portion as well.  Not a fully fledged out text editor, but the options are there, just need to code it in there (syntax highlighting, finding etc) if that is a desired feature.

The one thing that I have toyed with, is if there is an interest in FFMPEG/FFPLAY integration to have stations preprogrammed in there (say Bygolly OTR, Audio Noir etc) and be able to play those as well.  I don't know if there is an interest for that as well.  Let me know.  It would require that ffmpeg is installed and on PATH to work, but if one is dealing with audio manipulation at all, FFMPEG is a worthy suite of tools to have anyway.


Evan

On 2023-02-06 07:31 PM, Bill Clough via groups.io wrote:

I guess that a version of SQL is out of the question.
It seems that SQL could bring things up to date.

Bill

On 2/6/2023 6:35 PM, Wild West Designs wrote:
Big fan of Otter here.  Unfortunately, it is 32 bit, so that does present it with a limited life span.

I have been working on a version.  I'm trying to decide on the best way forward.  I have written a version in Go,  Python and in GDScript (I may stick with this one as it would be the easiest SDK for anyone else to download and start contributing, I just need to retool the code a bit, could also use CPP with it (already do for the sqlite portion), so there are more options with the game engine versus the others).  All versions are cross platform.  Go uses Fyne, OpenGL (which has lifespan issues), the python uses TK for it's UI.  Not bad, but it is an older looking UI.  GDScript uses the Godot engine, while the stable version still uses OpenGL, when Godot 4.0 releases, it should be using Vulkan.  I did have a version using C++ and Qt, but that would be massive for others to contribute to, so I decided to stick with the others.

My goal was to have it as cross platform as it can be and it will be open source as well, so anyone could submit changes as well on Gitlab (that's where I plan to host it).  I did update some of the Otter database, but it is based on the original Otter database for the most part.

Any thoughts, ideas, suggestions, let me know while in the refactoring stages and I'll let the group know when I have it on Gitlab.

Evan 
 


Michael Hingson
 

So again, what is Otter please?

 

From: main@OldTimeRadioResearchers.groups.io <main@OldTimeRadioResearchers.groups.io> On Behalf Of Wild West Designs via groups.io
Sent: Monday, February 6, 2023 6:33 PM
To: main@oldtimeradioresearchers.groups.io
Subject: Re: [OldTimeRadioResearchers] Otter

 

That I do not plan on having, unless someone wants to help with that.  Mainly for the reason you state, it wasn't forgiving.  It was very opinionated and even as a frequent Otter user, I hardly used it, because it was opinionated in a way that I didn't use.  Also doing something cross platform (I mainly run on Linux for instance) how directories/files are formatted are also different, so that would add another wrench in that plan.  Not to say that it couldn't be solved, but if the language doesn't have a means to address it (and even if the language does, sometimes it's a booger to set up), it's hard to handle.

It's a nice idea, but as of now, I don't plan on supporting it, unless I either find an easy way to handle it or someone more knowledgeable is able to take that forward (one of the reasons why I plan to open source it as well, even if I am unable to do it, someone else might and it would still be able to be made better.

 

Evan

 

On 2023-02-06 08:23 PM, Edward A. (Ted) Jones via groups.io wrote:

If we do Otter-driven file mgmt/renaming (local file changes), please make it forgiving, aka temp files that can be manually managed.

 

 

On Mon, Feb 6, 2023 at 8:53 PM, Wild West Designs

<evan@...> wrote:

To me, the benefits of using SQL versus SQLite are very, very small considering this isn't a web app dealing with many, many concurrent queries or being used even within a LAN and getting all of those queries at the same time, compared to the overhead of getting SQL up and running versus SQLite.  SQLite database would also make it easier to work with C++, Nim, Python, Go without really needing to make changes to the database that I already have, if it needs to be ported to something else (really the only thing that got me switching from language to language was UI frameworks and licenses there of, especially for desktop UI).  I think SQL was used in the original database as I had to export all the database to .txt files (it wouldn't read directly using SQLite and it has really good backwards compatibility, so I don't think it was just do to an older version of SQLite), from there turn those into .csv files with proper formatting and push those into the new database (it took me a while to make the python script to do that, but thankfully that was done, otherwise I don't know if I would have been able to do the program otherwise without starting from scratch).

 

I'll see about getting some screenshots.  I will be refactoring the UI and the theming (it uses Godot's default theme, so I don't think that is the best thing).  Right now, since I have been the only one using it, it does the usual database operations (retrieve, delete, get master list, add episode, delete episode).  I do eventually want to add in export CSV and Import CSV.  Goal would be to have it easier for many people to be working on different logs and really on the individual CSV is needed to be pushed to the repo etc.  I do have a note taking portion as well.  Not a fully fledged out text editor, but the options are there, just need to code it in there (syntax highlighting, finding etc) if that is a desired feature.

The one thing that I have toyed with, is if there is an interest in FFMPEG/FFPLAY integration to have stations preprogrammed in there (say Bygolly OTR, Audio Noir etc) and be able to play those as well.  I don't know if there is an interest for that as well.  Let me know.  It would require that ffmpeg is installed and on PATH to work, but if one is dealing with audio manipulation at all, FFMPEG is a worthy suite of tools to have anyway.

 

Evan

On 2023-02-06 07:31 PM, Bill Clough via groups.io wrote:

I guess that a version of SQL is out of the question.
It seems that SQL could bring things up to date.

Bill

On 2/6/2023 6:35 PM, Wild West Designs wrote:

Big fan of Otter here.  Unfortunately, it is 32 bit, so that does present it with a limited life span.

I have been working on a version.  I'm trying to decide on the best way forward.  I have written a version in Go,  Python and in GDScript (I may stick with this one as it would be the easiest SDK for anyone else to download and start contributing, I just need to retool the code a bit, could also use CPP with it (already do for the sqlite portion), so there are more options with the game engine versus the others).  All versions are cross platform.  Go uses Fyne, OpenGL (which has lifespan issues), the python uses TK for it's UI.  Not bad, but it is an older looking UI.  GDScript uses the Godot engine, while the stable version still uses OpenGL, when Godot 4.0 releases, it should be using Vulkan.  I did have a version using C++ and Qt, but that would be massive for others to contribute to, so I decided to stick with the others.

My goal was to have it as cross platform as it can be and it will be open source as well, so anyone could submit changes as well on Gitlab (that's where I plan to host it).  I did update some of the Otter database, but it is based on the original Otter database for the most part.

Any thoughts, ideas, suggestions, let me know while in the refactoring stages and I'll let the group know when I have it on Gitlab.

Evan 

 


Wild West Designs
 

A database program for OTR shows. Desktop application, not a web based one.  Look up say Dragnet, you'll get air dates, episode number, episode names and if it exists or not (or at least believed to exist or not exist).  The otter program had some other abilities, batch renaming of OTR audio files and comparing the log with the files that one would have within the directory (both of these extras, however was also subject to the opinionated nature of Otter as well, so mileage may vary in how successful the operations were).

Evan

On 2023-02-06 09:07 PM, Michael Hingson wrote:

So again, what is Otter please?

 

From: main@OldTimeRadioResearchers.groups.io <main@OldTimeRadioResearchers.groups.io> On Behalf Of Wild West Designs via groups.io
Sent: Monday, February 6, 2023 6:33 PM
To: main@oldtimeradioresearchers.groups.io
Subject: Re: [OldTimeRadioResearchers] Otter

 

That I do not plan on having, unless someone wants to help with that.  Mainly for the reason you state, it wasn't forgiving.  It was very opinionated and even as a frequent Otter user, I hardly used it, because it was opinionated in a way that I didn't use.  Also doing something cross platform (I mainly run on Linux for instance) how directories/files are formatted are also different, so that would add another wrench in that plan.  Not to say that it couldn't be solved, but if the language doesn't have a means to address it (and even if the language does, sometimes it's a booger to set up), it's hard to handle.

It's a nice idea, but as of now, I don't plan on supporting it, unless I either find an easy way to handle it or someone more knowledgeable is able to take that forward (one of the reasons why I plan to open source it as well, even if I am unable to do it, someone else might and it would still be able to be made better.

 

Evan

 

On 2023-02-06 08:23 PM, Edward A. (Ted) Jones via groups.io wrote:

If we do Otter-driven file mgmt/renaming (local file changes), please make it forgiving, aka temp files that can be manually managed.

 

 

On Mon, Feb 6, 2023 at 8:53 PM, Wild West Designs

<evan@...> wrote:

To me, the benefits of using SQL versus SQLite are very, very small considering this isn't a web app dealing with many, many concurrent queries or being used even within a LAN and getting all of those queries at the same time, compared to the overhead of getting SQL up and running versus SQLite.  SQLite database would also make it easier to work with C++, Nim, Python, Go without really needing to make changes to the database that I already have, if it needs to be ported to something else (really the only thing that got me switching from language to language was UI frameworks and licenses there of, especially for desktop UI).  I think SQL was used in the original database as I had to export all the database to .txt files (it wouldn't read directly using SQLite and it has really good backwards compatibility, so I don't think it was just do to an older version of SQLite), from there turn those into .csv files with proper formatting and push those into the new database (it took me a while to make the python script to do that, but thankfully that was done, otherwise I don't know if I would have been able to do the program otherwise without starting from scratch).

 

I'll see about getting some screenshots.  I will be refactoring the UI and the theming (it uses Godot's default theme, so I don't think that is the best thing).  Right now, since I have been the only one using it, it does the usual database operations (retrieve, delete, get master list, add episode, delete episode).  I do eventually want to add in export CSV and Import CSV.  Goal would be to have it easier for many people to be working on different logs and really on the individual CSV is needed to be pushed to the repo etc.  I do have a note taking portion as well.  Not a fully fledged out text editor, but the options are there, just need to code it in there (syntax highlighting, finding etc) if that is a desired feature.

The one thing that I have toyed with, is if there is an interest in FFMPEG/FFPLAY integration to have stations preprogrammed in there (say Bygolly OTR, Audio Noir etc) and be able to play those as well.  I don't know if there is an interest for that as well.  Let me know.  It would require that ffmpeg is installed and on PATH to work, but if one is dealing with audio manipulation at all, FFMPEG is a worthy suite of tools to have anyway.

 

Evan

On 2023-02-06 07:31 PM, Bill Clough via groups.io wrote:

I guess that a version of SQL is out of the question.
It seems that SQL could bring things up to date.

Bill

On 2/6/2023 6:35 PM, Wild West Designs wrote:

Big fan of Otter here.  Unfortunately, it is 32 bit, so that does present it with a limited life span.

I have been working on a version.  I'm trying to decide on the best way forward.  I have written a version in Go,  Python and in GDScript (I may stick with this one as it would be the easiest SDK for anyone else to download and start contributing, I just need to retool the code a bit, could also use CPP with it (already do for the sqlite portion), so there are more options with the game engine versus the others).  All versions are cross platform.  Go uses Fyne, OpenGL (which has lifespan issues), the python uses TK for it's UI.  Not bad, but it is an older looking UI.  GDScript uses the Godot engine, while the stable version still uses OpenGL, when Godot 4.0 releases, it should be using Vulkan.  I did have a version using C++ and Qt, but that would be massive for others to contribute to, so I decided to stick with the others.

My goal was to have it as cross platform as it can be and it will be open source as well, so anyone could submit changes as well on Gitlab (that's where I plan to host it).  I did update some of the Otter database, but it is based on the original Otter database for the most part.

Any thoughts, ideas, suggestions, let me know while in the refactoring stages and I'll let the group know when I have it on Gitlab.

Evan 

 

 


Wild West Designs
 

A few pictures of how I have the database program now.

Quite a bit of it is still rough, because I was really the only one using this, so I can handle a little rough around the edges.  Still have some work to do on the UI/theming.  Need to also add in keyboard shortcuts.  Like I said as well, have been toying with adding ffmpeg/ffplay integration, but I don't know if anyone would really care to have that.  Right now, I have a separate program (actually cli that handles what I use ffplay for, but if there is enough interest for those that use and have ffmpeg/ffplay installed, I would add in that functionality for otrDB to handle that.

I do have links to OTRR website and Radio Times directly.  Also to some NTR stuff as well (Colonial Radio (which I don't think is doing any new stuff anymore), RRCA, Jim French Productions and Graphic Audio as well).  If there are other links that anyone thinks that would be good sources to have, let me know.

Evan


Michael Hingson
 

Thanks.

 

From: main@OldTimeRadioResearchers.groups.io <main@OldTimeRadioResearchers.groups.io> On Behalf Of Wild West Designs via groups.io
Sent: Monday, February 6, 2023 7:49 PM
To: main@oldtimeradioresearchers.groups.io
Subject: Re: [OldTimeRadioResearchers] Otter

 

A database program for OTR shows. Desktop application, not a web based one.  Look up say Dragnet, you'll get air dates, episode number, episode names and if it exists or not (or at least believed to exist or not exist).  The otter program had some other abilities, batch renaming of OTR audio files and comparing the log with the files that one would have within the directory (both of these extras, however was also subject to the opinionated nature of Otter as well, so mileage may vary in how successful the operations were).

Evan

On 2023-02-06 09:07 PM, Michael Hingson wrote:

So again, what is Otter please?

 

From: main@OldTimeRadioResearchers.groups.io <main@OldTimeRadioResearchers.groups.io> On Behalf Of Wild West Designs via groups.io
Sent: Monday, February 6, 2023 6:33 PM
To: main@oldtimeradioresearchers.groups.io
Subject: Re: [OldTimeRadioResearchers] Otter

 

That I do not plan on having, unless someone wants to help with that.  Mainly for the reason you state, it wasn't forgiving.  It was very opinionated and even as a frequent Otter user, I hardly used it, because it was opinionated in a way that I didn't use.  Also doing something cross platform (I mainly run on Linux for instance) how directories/files are formatted are also different, so that would add another wrench in that plan.  Not to say that it couldn't be solved, but if the language doesn't have a means to address it (and even if the language does, sometimes it's a booger to set up), it's hard to handle.

It's a nice idea, but as of now, I don't plan on supporting it, unless I either find an easy way to handle it or someone more knowledgeable is able to take that forward (one of the reasons why I plan to open source it as well, even if I am unable to do it, someone else might and it would still be able to be made better.

 

Evan

 

On 2023-02-06 08:23 PM, Edward A. (Ted) Jones via groups.io wrote:

If we do Otter-driven file mgmt/renaming (local file changes), please make it forgiving, aka temp files that can be manually managed.

 

 

On Mon, Feb 6, 2023 at 8:53 PM, Wild West Designs

<evan@...> wrote:

To me, the benefits of using SQL versus SQLite are very, very small considering this isn't a web app dealing with many, many concurrent queries or being used even within a LAN and getting all of those queries at the same time, compared to the overhead of getting SQL up and running versus SQLite.  SQLite database would also make it easier to work with C++, Nim, Python, Go without really needing to make changes to the database that I already have, if it needs to be ported to something else (really the only thing that got me switching from language to language was UI frameworks and licenses there of, especially for desktop UI).  I think SQL was used in the original database as I had to export all the database to .txt files (it wouldn't read directly using SQLite and it has really good backwards compatibility, so I don't think it was just do to an older version of SQLite), from there turn those into .csv files with proper formatting and push those into the new database (it took me a while to make the python script to do that, but thankfully that was done, otherwise I don't know if I would have been able to do the program otherwise without starting from scratch).

 

I'll see about getting some screenshots.  I will be refactoring the UI and the theming (it uses Godot's default theme, so I don't think that is the best thing).  Right now, since I have been the only one using it, it does the usual database operations (retrieve, delete, get master list, add episode, delete episode).  I do eventually want to add in export CSV and Import CSV.  Goal would be to have it easier for many people to be working on different logs and really on the individual CSV is needed to be pushed to the repo etc.  I do have a note taking portion as well.  Not a fully fledged out text editor, but the options are there, just need to code it in there (syntax highlighting, finding etc) if that is a desired feature.

The one thing that I have toyed with, is if there is an interest in FFMPEG/FFPLAY integration to have stations preprogrammed in there (say Bygolly OTR, Audio Noir etc) and be able to play those as well.  I don't know if there is an interest for that as well.  Let me know.  It would require that ffmpeg is installed and on PATH to work, but if one is dealing with audio manipulation at all, FFMPEG is a worthy suite of tools to have anyway.

 

Evan

On 2023-02-06 07:31 PM, Bill Clough via groups.io wrote:

I guess that a version of SQL is out of the question.
It seems that SQL could bring things up to date.

Bill

On 2/6/2023 6:35 PM, Wild West Designs wrote:

Big fan of Otter here.  Unfortunately, it is 32 bit, so that does present it with a limited life span.

I have been working on a version.  I'm trying to decide on the best way forward.  I have written a version in Go,  Python and in GDScript (I may stick with this one as it would be the easiest SDK for anyone else to download and start contributing, I just need to retool the code a bit, could also use CPP with it (already do for the sqlite portion), so there are more options with the game engine versus the others).  All versions are cross platform.  Go uses Fyne, OpenGL (which has lifespan issues), the python uses TK for it's UI.  Not bad, but it is an older looking UI.  GDScript uses the Godot engine, while the stable version still uses OpenGL, when Godot 4.0 releases, it should be using Vulkan.  I did have a version using C++ and Qt, but that would be massive for others to contribute to, so I decided to stick with the others.

My goal was to have it as cross platform as it can be and it will be open source as well, so anyone could submit changes as well on Gitlab (that's where I plan to host it).  I did update some of the Otter database, but it is based on the original Otter database for the most part.

Any thoughts, ideas, suggestions, let me know while in the refactoring stages and I'll let the group know when I have it on Gitlab.

Evan 

 

 


Ryan Ellett
 

Someone can correct me, but I believe the original logs were adapted from Jerry H's site. OTRR members would update them as they came across new info and create new logs for newly discovered programs. I think users would have Otter compare their list of episodes for a series to the Otter log to see which episodes they were missing that were known to exist.
Ryan

www.RyanEllett.com


The Old Time Radio Researchers
"Saving the Past for the Future"




On Tuesday, February 7, 2023, 11:05:20 AM CST, Michael Hingson <mike@...> wrote:


Thanks.

 

From: main@OldTimeRadioResearchers.groups.io <main@OldTimeRadioResearchers.groups.io> On Behalf Of Wild West Designs via groups.io
Sent: Monday, February 6, 2023 7:49 PM
To: main@oldtimeradioresearchers.groups.io
Subject: Re: [OldTimeRadioResearchers] Otter

 

A database program for OTR shows. Desktop application, not a web based one.  Look up say Dragnet, you'll get air dates, episode number, episode names and if it exists or not (or at least believed to exist or not exist).  The otter program had some other abilities, batch renaming of OTR audio files and comparing the log with the files that one would have within the directory (both of these extras, however was also subject to the opinionated nature of Otter as well, so mileage may vary in how successful the operations were).

Evan

On 2023-02-06 09:07 PM, Michael Hingson wrote:

So again, what is Otter please?

 


Wild West Designs
 

I think that's the case, but I can only speculate.  Reason why is that there were some that I hadn't modified that look like they came from his logs (that he hadn't updated or needed to update whatever the case may be), but there were ones that I had updated.  Now that could have been a function of those particular logs not having been updated, since I doubt that Otter database has officially been updated since Jim's passing, at best it would have been like me, people have updated it on their own versions, but nothing officially happened that was distributed with the main program.

I think part of the issue was that (and it's been a long time since I last looked), updating the database required more rigid updating path.  I don't think otter exported CSV file to make it easy to transfer from one database to another.  It exported txt files, but even at that, the entries weren't formatted for a CSV use case either (no commas etc, at least last time I checked when I went through this conversion process).  I would hope that by adding CSV import/export abilities, that would it make it easier for others to do changes and just do a PR on the gitlab repo and update that way (and most other databases accept CSV, so if someone is needed it for a different database, that would help there as well).  It isn't relegated to one central place that most of the effort goes through.  At least that's the intent.

My hope is to have something that could easily be picked up by someone else in case there is ever that need.  Something happens, whatever that may be, it can still move along.

That's the hope anyway.

Evan

On 2023-02-07 11:35 AM, Ryan Ellett via groups.io wrote:

Someone can correct me, but I believe the original logs were adapted from Jerry H's site. OTRR members would update them as they came across new info and create new logs for newly discovered programs. I think users would have Otter compare their list of episodes for a series to the Otter log to see which episodes they were missing that were known to exist.
Ryan
 
www.RyanEllett.com
 
 
The Old Time Radio Researchers
"Saving the Past for the Future"
 
 
 
 
On Tuesday, February 7, 2023, 11:05:20 AM CST, Michael Hingson <mike@...> wrote:
 
 

Thanks.

 

From: main@OldTimeRadioResearchers.groups.io <main@OldTimeRadioResearchers.groups.io> On Behalf Of Wild West Designs via groups.io
Sent: Monday, February 6, 2023 7:49 PM
To: main@oldtimeradioresearchers.groups.io
Subject: Re: [OldTimeRadioResearchers] Otter

 

A database program for OTR shows. Desktop application, not a web based one.  Look up say Dragnet, you'll get air dates, episode number, episode names and if it exists or not (or at least believed to exist or not exist).  The otter program had some other abilities, batch renaming of OTR audio files and comparing the log with the files that one would have within the directory (both of these extras, however was also subject to the opinionated nature of Otter as well, so mileage may vary in how successful the operations were).

Evan

On 2023-02-06 09:07 PM, Michael Hingson wrote:

So again, what is Otter please?

 

 


Rizzo
 

Hi,

It does allow the export of the log files in fixed field spaced text files. The only problem i have found is that importing the logs, which you can do, will add and delete episodes, change air dates, episode numbers and titles, but it will not change the exists indicator. It seems to miss this one. If you compile the database in otter, it exports all its logs to txt format, backs up the database and then compiles the logs to create a new database that can be transported to another installation of otter.

i have also been contemplating writing a version in .net c# (the language i am most familiar with) to create a smart more user friendly ui. This of course wouldn’t fit with the one size fits all across all platforms unless it is rebuilt in two components, the engine component which handles the storage and manipulation of the logs at a data level and then various ui skins for different platforms that integrate with the engine part to present that to the user.

another thought i had was building the database as a hosted web service. Users could connect and download the database entirely or download and highlight changes. The database could be downloaded for local use detached from the internet but could support an online option. An admin ui is then used to update the central database. There would be costs involved with this though and security has to be factored in to the hosting.

Andy


Wild West Designs
 

The importing could be a problem with trying to iterate over a text file that isn't even formatted as a CSV file, just with the .txt extension.  I'm just speculating, but that would be my first inclination, but it's been years since I looked at Otter and that was when I exported from the original Otter database as the versioning of that database was fairly old (Otter program itself is Win98/XP era, so cross platform wasn't even a consideration I'm sure at that time as well and that also probably was reflective of some of the other design decisions as well).

Like I said before, I'm losing some functionality of Otter due to trying to handle cross platform using Godot as the SDK (which I would only build for Linux/Windows, web is supported, but I don't know if I would build those, but I do plan when this new version gets to beta, have it on Gitlab (probably backed up on Github as well, just to cover my bases), so anyone that wants to build it for Mac can do so and hopefully upload those to the repo as well).  While it can handle Android/iOS builds, that adds another can of worms (especially with the writing to database) that would also have to be handle by someone else.  Only other option would be to have it as some localhost webapp webview app on all platforms (think Electron, but without quite as much bloat, only reason why I would suggest webview for all platforms is that it gives a psuedo app feel using a stripped down browser window versus the default browser of the machine), that is still local to the machine, just runs on a local embedded server (which it would have to for database functionality), but that just breaks the local app feel even compared to using immediate mode UI like I am doing.  My main focus is more of the local usage, but still have functionality to make it easier to share edits.  Export a CSV file that could be vetted from a PR on the repo and the main db changed if all checks passed.

If trying to do a web first centric application, a different type of database would need to be used.  Sqlite is great for a lot of things, but many concurrent connections is not one of them.  Something eventually gets dropped when trying to commit changes.  It's definitely better for local use or even a small LAN usage, but it's pushing it with exposure to what potential could be on a public website.


---

Evan West



On 2023-02-09 03:53 AM, Rizzo wrote:

Hi,

It does allow the export of the log files in fixed field spaced text files. The only problem i have found is that importing the logs, which you can do, will add and delete episodes, change air dates, episode numbers and titles, but it will not change the exists indicator. It seems to miss this one. If you compile the database in otter, it exports all its logs to txt format, backs up the database and then compiles the logs to create a new database that can be transported to another installation of otter.

i have also been contemplating writing a version in .net c# (the language i am most familiar with) to create a smart more user friendly ui. This of course wouldn’t fit with the one size fits all across all platforms unless it is rebuilt in two components, the engine component which handles the storage and manipulation of the logs at a data level and then various ui skins for different platforms that integrate with the engine part to present that to the user.

another thought i had was building the database as a hosted web service. Users could connect and download the database entirely or download and highlight changes. The database could be downloaded for local use detached from the internet but could support an online option. An admin ui is then used to update the central database. There would be costs involved with this though and security has to be factored in to the hosting.

Andy