Bugs in 2.1.0

[paradiselost]

There seems to be a consistent fatal error in the Database Writer for VRS 2.1.

[2015-04-18 14:34:03.032 UTC] [t28] Database writer plugin caught exception on message processing: System.FormatException: String was not recognized as a valid DateTime.
at System.DateTimeParse.ParseExactMultiple(String s, String[] formats, DateTimeFormatInfo dtfi, DateTimeStyles style)
at System.DateTime.ParseExact(String s, String[] formats, IFormatProvider provider, DateTimeStyles style)
at System.Data.SQLite.SQLiteConvert.ToDateTime(String dateText, SQLiteDateFormats format, DateTimeKind kind, String formatString)
at System.Data.SQLite.SQLiteConvert.ToDateTime(String dateText)
at System.Data.SQLite.SQLite3.GetDateTime(SQLiteStatement stmt, Int32 index)
at System.Data.SQLite.SQLite3.GetValue(SQLiteStatement stmt, SQLiteConnectionFlags flags, Int32 index, SQLiteType typ)
at System.Data.SQLite.SQLiteDataReader.GetValue(Int32 i)
at System.Data.SQLite.SQLiteDataReader.get_Item(Int32 i)
at VirtualRadar.Database.Sql.GetDateTime(IDataReader reader, Int32 ordinal)
at VirtualRadar.Database.BaseStation.AircraftTable.DecodeFullAircraft(IDataReader reader, Int32& ordinal, Boolean createBaseStationAircraftAndFlightsCount)
at VirtualRadar.Database.BaseStation.AircraftTable.GetByIcao(IDbConnection connection, IDbTransaction transaction, TextWriter log, String icao)
at VirtualRadar.Database.BaseStation.Database.GetAircraftByCode(String icao24)
at VirtualRadar.Plugin.BaseStationDatabaseWriter.Plugin.FetchOrCreateAircraft(DateTime now, String icao24)
at VirtualRadar.Plugin.BaseStationDatabaseWriter.Plugin.TrackFlight(BaseStationMessage message)
at VirtualRadar.Plugin.BaseStationDatabaseWriter.Plugin.MessageQueue_MessageReceived(BaseStationMessageEventArgs args)

Today I discovered it was not only me but one of my feeders had the same error at exactly the same time and the Database Writer plugin stopped updating the Reports.

Looking back through my logs this error is common ever since the plugin was replaced from version 2.0. /plugins/database writer/options/ok seems to reset things and reports for today start logging at that time.

Caught an exception on a slow tick heartbeat event: System.FormatException: String was not recognized as a valid DateTime.

To check to see if this is a global problem check your log for this exception [2015-04-18 14:34:03.032 UTC].

Andrew any thoughts?

John
paradiselost

[agw]

What the message is saying is that an aircraft record in your BaseStation.sqb had a date that couldn't be read, it was invalid. There are a bunch of ways that you can format dates in SQLite database files (https://www.sqlite.org/datatype3.html, scroll down to 1.2), it could be that something has written records into the database using a format that differs to the one that BaseStation and VRS use? From memory I *think* the one that BaseStation uses is the text format.

As to why both of you have the same problem, I don't know I've got a vague recollection of you writing elsewhere about sharing BaseStation.sqb files, could they be using the same file (or at least the same aircraft records) as you?

I would expect you to hit that error every time that aircraft shows up, which would explain why you both got the error around the same time and why it keeps happening.

[paradiselost]

When auto routesupdate is enabled there is this exception behavior.

[2015-04-22 13:39:41.520 UTC] [t33] Exception caught during data download: System.InvalidOperationException: Could not download http://www.virtualradarserver.co.uk/Fil ... verage.csv: The remote name could not be resolved: 'www.virtualradarserver.co.uk' ---> System.Net.WebException: The remote name could not be resolved: 'www.virtualradarserver.co.uk'
at System.Net.HttpWebRequest.GetResponse()
at VirtualRadar.Interface.WebRequestHelper.<GetResponse>b__0(WebRequest r)
at VirtualRadar.Interface.WebRequestHelper.RepeatActionOnTemporaryErrorCondition[T,TResponse](T obj, Func`2 action, Boolean suppressRepeat)
at VirtualRadar.Interface.WebRequestHelper.GetResponse(WebRequest request, Boolean suppressRepeat)
at VirtualRadar.Database.StandingData.StandingDataUpdater.DefaultProvider.DownloadToStream(String url, Stream stream, Boolean urlIsGzipFile)
--- End of inner exception stack trace ---
at VirtualRadar.Database.StandingData.StandingDataUpdater.DefaultProvider.DownloadToStream(String url, Stream stream, Boolean urlIsGzipFile)
at VirtualRadar.Database.StandingData.StandingDataUpdater.DefaultProvider.DownloadLines(String url)
at VirtualRadar.Database.StandingData.StandingDataUpdater.Update()
at VirtualRadar.Database.StandingData.BackgroundDataDownloader.Heartbeat_SlowTick(Object sender, EventArgs args)

Even though it appears to be non-fatal, the manual method of downloading routes updates works normally and it must therefore resolve the address of the server satisfactorily.

John
paradiselost

[paradiselost]

What the message is saying is that an aircraft record in your BaseStation.sqb had a date that couldn't be read, it was invalid. There are a bunch of ways that you can format dates in SQLite database files (https://www.sqlite.org/datatype3.html, scroll down to 1.2), it could be that something has written records into the database using a format that differs to the one that BaseStation and VRS use? From memory I *think* the one that BaseStation uses is the text format.

As to why both of you have the same problem, I don't know I've got a vague recollection of you writing elsewhere about sharing BaseStation.sqb files, could they be using the same file (or at least the same aircraft records) as you?

I would expect you to hit that error every time that aircraft shows up, which would explain why you both got the error around the same time and why it keeps happening.

The exception is valid but it shouldn't disable the Database Writer plugin like it did until it was manually re-enabled at a later time at which time reset the Reports to the start time it was re-enabled.

An event like this has not reoccurred.

John
paradiselost

[agw]

The remote name could not be resolved: 'www.virtualradarserver.co.uk'

This happens from time to time - it's the .NET DNS resolver, it's timing out too quickly. I put some code in to do some retries when this happens during the lookup of addresses for receivers and rebroadcast servers, I can't remember if I did the same for the routes download stuff now. I'll take a look. However, VRS checks for new routes once an hour (they're only compiled once a day, so you're not downloading new routes 24 times a day) so if one check fails because the DNS resolver timed out then the next one will work, the PC's DNS client will have the address cached by the next lookup.

The exception is valid but it shouldn't disable the Database Writer plugin like it did

The database writer disables writes to the database when it sees a database exception that indicates some kind of problem with the database. If it didn't then a corrupt database could cause it to keep everything that needs to be flushed out to the database in a queue that will grow forever.

[tutpipos]

Hello. I am from Belarus, so I apologize for my language english. I'll try to write the problem of text available. Recently I installed a new version of VRS 2.1.0.42181 and a new version of DatabaseWriter. A week ago, found that in the main window in the "Jets tracked" a figure larger than the list in the browser. This can be seen in the screenshot. At the same time revealed another problem. I am leaving in the morning for work, leave your computer on, I come home at night, look in the browser - planes fly, messages from them go. I make a report for the current day, and the report is empty. Restarts VRS - and the base begins to write since the program was rebooted. That is a problem. In the old version of such problems were observed.

[agw]

The first point about the different Aircraft Tracked numbers - VRS keeps a list of every aircraft that a receiver is currently picking up messages for. When an aircraft goes out of range of the receiver it still stays in that list for about 10 minutes after its last message. However it gets taken off the web site about a minute or so after its last message. The server's "aircraft tracked" figure is a count of how many aircraft are in the aircraft list for the receiver, 62 in your example. The web site's "Tracked" figure is a count of how many of those aircraft are currently transmitting messages, 34 in your example. It's normal for the server to say that it is tracking more aircraft than are being displayed.

There are a couple of reasons why the database writer will stop writing to the database. The most likely reason is that something else had the database locked when it tried to write to it. That's a bug, it should not abandon writes when it encounters a lock, it should wait and then try to do the write again. I've fixed that for the next version, or rather I was in the middle of fixing it the last time I had a chance to work on VRS.

The other reason is that the database could be corrupt. If VRS gets an exception that it was not expecting when it writes to the database file then it just stops writing, it gives up.

If you go into Tools | Plugins after the next time you notice that it's stopped writing then the section for the database writer should tell you why it stopped writing. It will probably say that it encountered an exception, if the exception message talks about locks then you're hitting the lock bug, if it talks about some other kind of exception then let me know.

[Jester]

Hi,

I'm running a preview version of the 27th, and all MIL aircraft are being reported as Civil ??

EDIT:

Figured it out, something went wrong on the data download, re downloaded and now the reports are ok again.

[Rick]

I've run into an issue with the Linux version of VRS 2.1.0. The problem occurs when I try to export the settings.

I go to VRS >> Options >> Web Site >> Initial Settings. When I click on the Settings Site link it opens a page in Firefox. (So far so good!) The problem is that the Firefox settings.html is completely blank. No Remove All, no Refresh , no Export Settings and no Import Settings. Just a blank html page.

Is this a bug or is this pilot error on my part?

Thanks,

Rick

[agw]

Firefox on Linux appears to be ignoring synchronous AJAX calls. Unfortunately the language file relies on being loaded synchronously. If you press Ctrl+R then it usually gets it working, I'll be addressing this in the next release.