Bug / Unstable Dbserver - client access.

Hi, there seems to be an issue with DbServer with the latest snapshot, with a remote client crashing after generating a sechedule. It’s a local database, with dbserver running serving on a local network.

If someone could try and replicate this between server and client to see if the result is the same it would be appreciated.

Using

mAirList 6.1 Beta build 3834

Are you using Hook Containers? We identified a problem with that, should be fixed in b3835.

Hi Torben,

Nope - No hook containers at all.

Hm. Well… Can you tell us again which error message you see exactly, on which side of the setup (client/server)?

Hi Torben,

Client side - alert dialog - HTTP/1.1 500 internal server error.

This seems to appear just after scheduling just before log save to db.

Cheers,

Any error on the server side in the log messages?

Within the server log window it had stated database is locked when trying to read from the client.

Is there more than one mAirList.exe process accessing the database file?

I’ll check, don’t think so - I’m running main playout instance then just trying to connect from the remote client - remote client connects, I can read everything in the database from the remote client - it’s just when it comes to end of scheduling routine when it gives the error.

Nope, just those two instances running - I’ve even just tried with just DBserver running (without mAirlist itself open) and still getting database is locked issue.

Does it happen with all write accesses (e.g. editing of items) or only at the end of scheduling?

Just at the end of scheduling - I’ve just tested editing a cut artist and title from the client and that works fine…

Next test: Schedule from local PC. Same error?

No error scheduling from the local PC - that is working fine.

Hi Torben,

Any progress on finding this bug yet?

Cheers

Not even able to reproduce :frowning:

Hi Torben,

Just wanted to update after some testing trial and error the issue I’ve managed to fix, I had to create a new clock and assign, and that had prevented the error / so something in the original clock template was causing the issue.