Empty duration for added files.

[bigretromike]

User have empty durations for files that are in collection. Maybe mediainfo is unable to get that information ?

Oryginal issue https://github.com/bigretromike/nakamoriplugin/issues/65 ask @kaigame for more information

[bigretromike]

I also have few of those in SELECT * FROM jmmserver.videoinfo where duration = 0 Some of them use cross-ref because even having duration = 0 in that table result in showing duration in XML result.

Probably MediaInfo failed there, Nakamori handle this (v1.3.1) fine but shouldn't we somehow mark them to be properly parsed by mediainfo?

[bigretromike]

Its not mediaInfo fault. As we use extra old version results of both are very similar with 3 little difference (for the '0' duration files anyway)

[bigretromike]

I'm unable to reproduce this behavior in 3.6 with same files that been '0' in fresh 3.5. MediaInfo isn't reporting '0' duration. The only time when it can be '0' is this code:

                VideoInfo vinfo = repVidInfo.GetByHash(vlocal.Hash);
...
                if (vinfo == null)
                {
                    vinfo = new VideoInfo();
                    vinfo.Hash = vlocal.Hash;
                    vinfo.Duration = 0;
                    vinfo.FileSize = fi.Length;
                    vinfo.DateTimeUpdated = DateTime.Now;
                    vinfo.FileName = filePath;
                    vinfo.AudioBitrate = "";
                    vinfo.AudioCodec = "";
                    vinfo.VideoBitrate = "";
                    vinfo.VideoBitDepth = "";
                    vinfo.VideoCodec = "";
                    vinfo.VideoFrameRate = "";
                    vinfo.VideoResolution = "";
                }

vlocal wasn't null in anycase, repVidInfo.GetByHash(vlocal.Hash) return null even when vlocal.Hash had hash

Currently GetByHash use cache, maybe before it didn't update as database had that row and cache didn't resulting with Null and having empty mediaInfo.

[bigretromike]

Let's see if this will encounter on 3.6, if not then @maxpiva cache update in 3.6 did the job.

[Stonedestroyer]

Alright so on old version 3.5.0.2, I had

SELECT * FROM jmmserver1.videoinfo where duration = 0;
/* Affected rows: 0  Found rows: 592  Warnings: 0  Duration for 1 query: 0,016 sec. (+ 0,109 sec. network) */

And now on this commit which is 3 commits behind latest I have

SELECT` * FROM jmmserver.videoinfo where duration = 0;
/* Affected rows: 0  Found rows: 7  Warnings: 0  Duration for 1 query: 0,016 sec. */

https://github.com/japanesemediamanager/jmmserver/commit/048d31b8e8a27e400d130b7714d4aee389b51190 - The commit I am on

Also these files have the problem, mysqlrip.zip

@bigretromike

[bigretromike]

From my tests there is no rule about which files are affected. One time those files from mysqlrip.zip other times there wont tigger this bug. Its probably somekind of query bug where repVidInfo dont get updated.

[hidden4003]

This bug occurs more frequently when used with cloud folder after importing my ~1200 files from amazon cloud drive I had 207 files with 0 duration, but @maxpiva made a check for that on server startup. Currently there is no solution, only a workaround - restart the server. Although we might need some periodic check as it is inconvenient to restart server every time some files are added.

[maxpiva]

With the media web cache, this issue should be minimized, this issue appears when the mediainfo.dll fails to get the media information from the file. (In case of local filesystem, Nas disconnects, file locking, moving, playing, etc) In case of cloud (Timeouts, internet problems, etc). Keep in mind previous mediainfo.dll with cloud, have issues. Now resolved. Anyway, not only at startup, every time the use wants to do something with the media info, (Example, Kodi list, Plex Play, JMMClient play, etc). If the Duration==0 the mediainfo.dll is called again to refresh the information. BTW, videoinfo is deprecated in 3.6.5. To reduce the number of checks, in the next version, if mediainfo is unable to retrieve the media information i'll return null, instead of an empty filled Media object which happens to have empty duration.

[maxpiva]

Current intented behavior is this... If mediainfo fails. Media will got null. On Startup will try to refresh. If someone ask for the file, Kodi, Plex, etc.. JMMServer will try to refresh. When we have the media cache online, this will minimized also.