Server not running AutoSync or Chapter Image Extraction

[das7002 0]

I recently got a month of Emby Premiere to see if I could use the autosync feature to transcode my live tv recordings so that direct play is possible. And it works, if I click on every, single, recording, and hit sync. Using the sync button from the recordings tab of live tv does not work at all. It adds a sync job for a file from my TV library, that's already been transcode synced, but then doesn't do anything else.

 

I also am having issues with chapter image extraction, it worked great for the first five recordings I did and now it refuses to do anything. Even manually triggering it it runs for 1 second and that's it. I really do want Emby to work for me, but it really seems like it wants to fight me on everything.

[Luke 42077]

I'll test the sync function on the recordings tab. Regarding chapters, sometimes ffmpeg will fail to extract chapters from certain videos. It is normal for it to happen once in a while. unfortunately it tends to happen a little more often with recorded tv simply because i don't think the ffmpeg developers do quite as much testing with wtv/transport streams. Of course, if that wtv is converted to a more streaming friendly format then the problem goes away.

[das7002 0]

I found another issue, when emby-server restarts it will "resync" everything again, even if it's already been transcoded. Why in the world would it do that?

 

Ive been trying to find out if there is just something not right with one of the config files and went through a few of the sqlite databases to try and figure it out, but I don't see duplicate jobs anywhere, so I am not sure what is causing it, I hope someone has some insight.

Edited October 14, 2015 by das7002

[Luke 42077]

Sync is a sync process. It's not a one-time copy. If the destination files are removed, the server will resync them. You can stop this by just deleting the sync jobs after you're done.

[das7002 0]

But they aren't removed, I'm looking right at the already transcoded files that are being queued up again, if emby-server ends up being restarted it's like it has amnesia about the sync jobs and forget what was already transcoded so it just does it again for no good reason.

 

If you are saying that not only does autosync on new content not work, but after it's done I have to go back and delete the jobs then requiring emby premeire for access to the sync feature is a very bad idea, it is nowhere near as well done as I thought it would be.

[Luke 42077]

or perhaps at the time of the sync the file is being reported as non-existent by the file system. that would be another reason.

[das7002 0]

I'm not sure how that is possible when the only thing that happens is the daemon itself restarts.

 

The files never go away on the file system and just end up overwritten when the transcode runs again and moved back to sync folder.

[Luke 42077]

i wonder if there is some kind of an access problem, because if there is transcoding involved then it is actually ffmpeg that is writing the file. a good data point would be to try syncing something that doesn't transcode and then see if that has the same problem or not. you can do that by forcing original quality.

[das7002 0]

The directory and it's parent that it is syncing to is owned by emby:emby (/home/emby-media/tsync) and mono as well as ffmpeg are running as emby

 

So if it's a permission issue it's not one I've ever seen.

Edited October 14, 2015 by das7002

[Luke 42077]

i understand but the results of that test would provide useful information. after it syncs you can do something like change a date attribute or overwrite the file with a zero byte file. then see if it gets resynced later and overwritten.

[das7002 0]

Well I did some more investigating and I have some more baffling results, everything works fine as long as the emby-server daemon does not restart, it seems as though there is a bug with the saving of the sync state.

 

Here is the directory listings before the daemon restarts

 

And the sync window from before daemon restarts

 

 

Everything looks fine and works great, even on FireTV app, direct play and everything. Then I restart the daemon and look at directories again

 

Looks almost identical to me, the same goes for the sync tab on manage server

 

Looks almost identical!

 

One big issue at this point though, direct play no longer works on FireTV app even though it clearly says SYNCED on that tab.

 

Then the cloud sync task triggers and you get this

 

 

Which is rather curious as the directories still look fine

 

Nothing has changed since the before server restart screenshot for the directories

 

And then the convert media task triggers

 

And the server starts conversion again on everything except for that one doctor who episode I transcoded manually on an entirely different machine, which is quite curious.

 

And again, the directories show all of the transcoded files there, but it is running the transcode again.

 

So my best guess is the server is not saving the state of the sync jobs, or not reading the metadata properly on the files, as the only one that does not get transcoded ever is the doctor who episode I transcoded manually with

 

ffmpeg -i Doctor\ Who\ S09E03\ Under\ the\ Lake.ts -vf scale=-1:720 -c:v libx264 -c:a ac3 -ac 2 -crf 20 -preset veryfast "Doctor Who S09E03 Under the Lake x264.720p.2.mp4"

 

 

 

And this is the only mention of the tasks in the server log

 

 

Honestly, I hope this testing does help you, but I'm seriously considering writing my own 'sync' and transcode because the one that is built in with emby is absolutely garbage, and I hate to say that as Emby is far and away the best at what it does and has the most seamless HDHomeRun integration out of anything, but this transcoding thing makes it very difficult to use.

 

 

[Luke 42077]

Thanks. This is resolved for the next release.