VLC playing vid over samba stuttering?

Question

I've got a strange issue in my WebApi service. Once in a while it throws an exception while trying to read the data from Postgres Db

    System.InvalidOperationException: A second operation started on this context before a previous operation completed. This is usually caused by different threads using the same instance of DbContext.
For more information on how to avoid threading issues with DbContext, see https://go.microsoft.com/fwlink/?linkid=2097913.\n   at Microsoft.EntityFrameworkCore.Internal.ConcurrencyDetector.EnterCriticalSection()\n   at Microsoft.EntityFrameworkCore.Query.Internal.QueryingEnumerable`1.AsyncEnumerator.MoveNextAsync()

There is plenty of info regarding this case but all of the articles deal with DbContext being registered with incorrect ServiceLifetime. But the DbContext that I'm using has been registered as Scoped (I've inspected the serviceCollection's registrations) using AddDbContextPool extension method, so it shouldn't throw such an error. Another important point: this issue sometimes occurs in Production but I wasn't able to reproduce it locally.

So, I would greatly appreciate help regarding the following questions

1. How come I still get this exception if DbContexts have been regitered as Scoped?
2. Am I right assuming that DbContext registered with ServiceLifetime.Scoped should not cause such an error? Or do I need to create scopes explicitly (e.g. via ServiceScopeFactory)?

Bonus questions 3) Are there any ways to reproduce this issue locally (specifically with AddDbContextPool extension usage)? I'd like to reproduce it because this way I will able to confirm that my fix works, otherwise I'll need to deploy these fixes to PDN and try them there. 4) Obviously, switching from AddDbContextPool to something like

services.AddDbContext<DbContext>(contextOptions =>
            contextOptions.UseNpgsql(connStr, npgOptions =>
            {
                ...
            }), ServiceLifetime.Transient);

is likely to solve the issue but this approach will cause performance drop. I was wondering if anyone knows how big this drop is going to be? Maybe someone has made this specific comparison (Pool vs Non-Pool)

Solution

It's entirely possible you simply don't have enough bandwidth to seek quickly. Our local wifi set-up pushes just under 300mbit on a good day, and seeking can be somewhat of an issue - but stuff plugged into the gigabit LAN has absolutely no such issues.

The problem is seeking files takes a little bit more data than you'd actually expect. Streaming servers work differently when you seek than something like VLC when it thinks it's looking at a real local file. A streaming server absolutely may help - though you're probably going to end up with re-encoded video (or a lot of CPU time used on the server), if that is something you're happy with then it's probably worth a shot.

If your issue is more with stuttering video you can change the cache config in preferences. If you change the Show settings option to All and go to Input/Codecs there is an option named File caching (ms) - but this will probably in fact make your seeking issue worse (it will have to pull more data before it can start playing video).

Comments

[mjwills]

Am I right assuming that DbContext registered with ServiceLifetime.Scoped should not cause such an error? No, not necessarily.

[mjwills]

Are you using Task.Run or threads and accessing the database from there?

[Svyatoslav Danyliv]

Usually this error appear when you forgot to put await in some place.

[makumazan84]

@SvyatoslavDanyliv you are right, but I've already double-checked it and all awaits are in place

[makumazan84]

@mjwills 1. I use async-awaits to get the data from Db, no explicit Task.Run or System.Thread usage. The concurrency issue kicks in due to multiple service calls.

[makumazan84]

@mjwills "Am I right assuming that DbContext registered with ServiceLifetime.Scoped should not cause such an error? No, not necessarily. " --- please tell me more about such case(s), maybe this is the issue that I've ran into

[Svyatoslav Danyliv]

So, ensure that the same context not used in different tasks. DbContext is not thread-safe.

[makumazan84]

@SvyatoslavDanyliv You are right, that's where the trouble occurs. But my DbContext is registered as Scoped which theoretically guarantees that an instance of DbContext is created per scope... and for some unknown reason I still have this issue

[Svyatoslav Danyliv]

Scoped means that you have to create scope in each Task. For Controller call ASP.NET automatically creates scope.

[mjwills]

please tell me more about such case(s), Check the second and third comments. They are the usual two causes (also see go.microsoft.com/fwlink/?linkid=2097913 - the link in your error message). We can't help further without a minimal reproducible example.

[mveroone]

There are definitly client/server programs that can stream video without forced transcoding, even with subtitles. (although i'm not here to advise one, even if I have my favourite) That suposes the client player has the required codecs, though. (which my tablet doesn't have for example)

[makumazan84]

This might be the case, however, the core question here is: why do we have this issue in a first place, if DbContext has been registered as Scoped?

[Brecht De Rooms]

In his specific case he is calling the methods from within one request, as far as I know scoped makes a DbContext per request so Scoped would not help you here iirc.