Jump to content

Recommended Posts

fallenwitch3r
Posted

Nope, same error here.

Screenshot 2021-11-19 171119.png

  • Thanks 2
BaukeZwart
Posted
2 minutes ago, chef said:

Okay, I'm not sure a proper web socket connection has been created then.

If you restart the server instance, does the error disappear?

No, same error on Emby server reboot

  • Thanks 1
Posted

This is very interesting.

@fallenwitch3r do you also see a websocket error in your logs?

fallenwitch3r
Posted (edited)
3 minutes ago, chef said:

This is very interesting.

@fallenwitch3r do you also see a websocket error in your logs?

since updating to the newest emby build

Screenshot 2021-11-19 171642.png

Edited by fallenwitch3r
  • Thanks 1
Posted (edited)

Hi @Luke we are noticing some udp web socket errors for the beta release here.

Stack trace shows they seem to be thrown  in  the "UpdateStatusAfterSocketErrorAndThrowException" method... maybe.

It may also only be affecting Linux distrobutions.

 

Edited by chef
Posted
54 minutes ago, fallenwitch3r said:

since updating to the newest emby build

Screenshot 2021-11-19 171642.png

Which OS are you on?

fallenwitch3r
Posted

Ubuntu 20.04.3 LTS

  • Like 1
Posted

further examination of the logs show that it might be a permission issue.

System.Net.Sockets.SocketException: System.Net.Sockets.SocketException (13): Permission denied

It's possible that when emby updated their version of ffmpeg, the new version  wasn't given proper permissions.

that is only a guess. 

We'll wait to see if Luke has time to respond. We probably stumbled on a beta bug, which is actually great work.

 

  • Agree 1
  • Thanks 1
Posted

You mean in the Linux distro's right @chef ?

I'm running the latest Windows Beta and IntroSkip and thumb images appear to be ok ?

  • Agree 1
Posted
52 minutes ago, rbjtech said:

You mean in the Linux distro's right @chef ?

I'm running the latest Windows Beta and IntroSkip and thumb images appear to be ok ?

yeah. Linux seems to be having permission  issues with a udp web socket connection in the recent beta release. 

It seems to have something to do the ffmpeg suite.

  • Thanks 1
Posted
27 minutes ago, chef said:

Hi @Luke we are noticing some udp web socket errors for the beta release here.

Stack trace shows they seem to be thrown  in  the "UpdateStatusAfterSocketErrorAndThrowException" method... maybe.

It may also only be affecting Linux distrobutions.

 

server log?

  • Thanks 1
fallenwitch3r
Posted
16 minutes ago, Luke said:

server log?

PM!

  • Thanks 1
fallenwitch3r
Posted

Anything new? Bug, Feature? 😅

Posted

I have the same feature on my ubuntu server

  • Thanks 1
Posted

Have any Windows users seen this issue ?

It appears to be related to the new emby Beta Linux distro - @Luke is investigating...

fallenwitch3r
Posted (edited)

Has anyone figured out what the problem is and if so, when will it be fixed? Because this malfunction causes a very high cpu load when using the plugin

The server crash if i use the plugin to set start and end points

Edited by fallenwitch3r
Posted

Given that you guys are now detecting credits as well are the devs aware that they could use this to further improve the "play next" feature?
Right now it sometimes shows up to late or to early but if the correct credits time is available it could be tweaked, I guess.

Just a thought I had right now while detection is running.

PS: From what I see in the logs the detection has been tweaked, will report in a couple of days when it's through my library.

  • Agree 2
Posted
2 hours ago, fallenwitch3r said:

Has anyone figured out what the problem is and if so, when will it be fixed? Because this malfunction causes a very high cpu load when using the plugin

The server crash if i use the plugin to set start and end points

We are still waiting I word about an update.

So, you are saying that when you edit the start times in the UI, and hit 'save', you experience high CPU usage?

 

That is interesting.

Posted
26 minutes ago, neik said:

Given that you guys are now detecting credits as well are the devs aware that they could use this to further improve the "play next" feature?
Right now it sometimes shows up to late or to early but if the correct credits time is available it could be tweaked, I guess.

Just a thought I had right now while detection is running.

PS: From what I see in the logs the detection has been tweaked, will report in a couple of days when it's through my library.

Looking forward to the feedback. Thanks neik!

fallenwitch3r
Posted

Not the editing causes the high CPU load. The image loading is the problem. The high CPU load returns every time I reload the site or change the season or the series. 

Is it possible to save temporarily the start, stop generated pictures?

Posted

I am having the same "problem" with the high CPU usage.

Every time when I change the series or season, it is generating the intro Sart/End miniatures, and the CPU usage is really high. (It seems that it is not saving it)

The version .22 seems to fixed the detection stop.

Other then that, the accuracy is very high. although I am using Detection confidence 1.

 

I am running on Synology NAS

Posted (edited)

We are extracting the images using ffmpeg on the fly, so it will spike the CPU.

We don't cache the images. It was a trade off of disk space or CPU.

We figured that because the plugin configuration page wasn't going to be opened very often (just to check results every once in a while), it was best to extract images in the fly.

 

 

Edited by chef
  • Agree 1
fallenwitch3r
Posted (edited)

Just my 5 cents but I think it would be better to extract the pictures after saving the right start/end time to prevent the high CPU load. Maybe with a resolution of 320x320. 

The random stopping during the detection progress seems to be fixed.

Edited by fallenwitch3r
  • Like 1
  • Thanks 1
Guest
This topic is now closed to further replies.
×
×
  • Create New...