How to debug filename scrapping?

[GregMo 24]

Can anyone point me to a log file or some such that I can look into to debug file name scrapping?  The following series, for some reason, will not scrape with the 1x01 format.  If I rename it with s1e1 it does it fine, but I don't want to have to rename the whole series and there's no good reason that it shouldn't find this one as it does fine with many others named the same way.

 

Edited January 3, 2022 by GregMo

[GrimReaper 4762]

That is one of the supported naming conventions, so not sure why it's failing, some more context might be needed, like complete filefolder structure.

Emby TV Naming : Emby

Anyway, server log (embyserver.txt) should show you what is happening when querying.

[GregMo 24]

7 hours ago, GrimReaper said:

That is one of the supported naming conventions, so not sure why it's failing, some more context might be needed, like complete filefolder structure.

I did wonder about that for a moment until I renamed a handful of files using s1e1 format and it worked.  I've pared this down as far as I can think of to eliminate anything that could be confounding the issue and I'm at a loss.

I figured the answer might be in the log file but as quick skim of it didn't reveal anything.  I was hopeful for some keywords or some such to specifically search for.

[Luke 42085]

Can we please look at specific examples of file names? Thanks.

[GregMo 24]

The filenames are shown in the image, just add an ".mkv" onto the end of them.

 

 

Edited January 3, 2022 by GregMo

[GregMo 24]

The only thing I can find from the log file that looks like it might be a problem is this:

 

2022-01-03 16:08:26.642 Error Server: Error processing request
	*** Error Report ***
	Version: 4.6.7.0
	Command line: C:\Users\GregMo\AppData\Roaming\Emby-Server\system\EmbyServer.dll
	Operating system: Microsoft Windows 6.2.9200
	Framework: .NET Core 3.1.21
	OS/Process: x64/x64
	Runtime: C:/Users/GregMo/AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll
	Processor count: 4
	Data path: C:\Users\GregMo\AppData\Roaming\Emby-Server\programdata
	Application path: C:\Users\GregMo\AppData\Roaming\Emby-Server\system
	System.InvalidOperationException: System.InvalidOperationException: Response Content-Length mismatch: too many bytes written (138988070 of 138987552).
	   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ThrowTooManyBytesWritten(Int32 count)
	   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.VerifyAndUpdateWrite(Int32 count)
	   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.Advance(Int32 bytes)
	   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpResponsePipeWriter.Advance(Int32 bytes)
	   at System.IO.Pipelines.PipeWriter.CopyFromAsync(Stream source, CancellationToken cancellationToken)
	   at Emby.Server.Implementations.HttpServer.FileWriter.WriteToAsync(IResponse response, CancellationToken cancellationToken)
	   at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost appHost, IRequest httpReq, IResponse httpRes, RestPath restPath, String responseContentType, CancellationToken cancellationToken)
	   at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IRequest httpReq, ReadOnlyMemory`1 urlString, ReadOnlyMemory`1 localPath, CancellationToken cancellationToken)
	Source: Microsoft.AspNetCore.Server.Kestrel.Core
	TargetSite: Void ThrowTooManyBytesWritten(Int32)

 

[pwhodges 2014]

2 hours ago, GregMo said:

The filenames are shown in the image, just add an ".mkv" onto the end of them.

The paths are not shown, though, and they also need to be considered.

Paul

[GregMo 24]

3 minutes ago, pwhodges said:

The paths are not shown, though, and they also need to be considered.

Paul

If changing the filenames to s1e1 solves the problem then why would you possibly need to consider the path?

[Happy2Play 9783]

23 minutes ago, GregMo said:

If changing the filenames to s1e1 solves the problem then why would you possibly need to consider the path?

It shouldn't but with the context you have provided I cannot reproduce the issues you are having.  But a guess without knowing full structure and naming is one naming scheme is more resilient than the other.

And as for the log snippet the full log is needed for context.

[GregMo 24]

3 hours ago, Happy2Play said:

... I cannot reproduce the issues you are having. 

That's sort of the point of my post.  I can't reproduce the problem with any other of the series that I have that are in the same path.  I'm hopeful to find out how to properly debug this myself.  I have 103 different TV series and to my knowledge, thus far, this is the only one I have this problem with but I'd really like to figure out to debug this in case it shows up in another series down the road.

I'm guessing the issue is somehow related to the fact that the parent folder has/had a "+" in the name.  I took it out, along with some other fluff, and it now seems to work correctly.  This still doesn't explain how that s1e1 worked fine just as it was which is why I'd like to know how to best debug this issue without all the trial and error.

[Luke 42085]

Can we please see full path examples? Thanks.

[GregMo 24]

3 hours ago, Luke said:

Can we please see full path examples? Thanks.

I sent a PM.