Jump to content

Live TV Unable To Record On Schedule


Theodore

Recommended Posts

Theodore

I'm not sure when this started as most of the shows I record only started coming back for first-runs in the past week or so, but I am getting the following errors in Scheduled Tasks for recording shows by schedule:

 

Task Scheduler failed to start "\Emby Recording Family Guy Sun, 06 Oct 2019 21 29 00 GMT" task for user "DomainName\ServerName$". Additional Data: Error Value: 2147943645.

 

Task Category: Task Start Failed

 

Last Run Result: "The operation being requested was not performed because the user has not logged on to the network. The specified service does not exist. (0x800704DD)"

 

I am recording with an HD Homerun using OTA Digital antenna. The server is 2012R2 with Emby set to run as a service. It looks like Emby is building the scheduled tasks with "Run only when user is logged on" instead of what should be "Run whether user is logged on or not" in the task settings. It has to have been an update sometime since March-ish of this year as that is the last time I know that I had shows scheduled to record.

Link to comment
Share on other sites

Hi, we haven't tested waking the server when running as a service, so this may not work. If you use the server as an application, it will work.

Link to comment
Share on other sites

Theodore

Hi, we haven't tested waking the server when running as a service, so this may not work. If you use the server as an application, it will work.

 

I haven't run the server as an application in YEARS and this worked exactly as described up until an update sometime earlier this year. I cannot believe I am the only person running this as a service as it has been a function of Emby since the beginning.

 

I've been looking for a PowerShell way to correct the scheduled tasks to what they should be created as, but so far all I am finding is ways to create new tasks. Here is the code you can use to create them as such:

 

$principal = New-ScheduledTaskPrincipal -UserID "MYDOMAIN\user_for_scheduled_task" -LogonType S4U -RunLevel Highest
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "Task-1" -Description "Very Important Task-1" -Principal $principal
Link to comment
Share on other sites

pwhodges

I run Emby as a service in Windows using nssm to start it on machine startup (i.e., not the built-in service facility), and have had no recording issues such as you describe.

Edited by pwhodges
Link to comment
Share on other sites

The issue isn't the actual recording proceed, it's about being able to wake up the server if it is in sleep mode.

Link to comment
Share on other sites

pwhodges

Ah, sorry for the noise.  I don't let my server sleep, as it needs to be accessible at all times without delay (it runs a mail server, for instance).

Link to comment
Share on other sites

Theodore

The issue isn't the actual recording proceed, it's about being able to wake up the server if it is in sleep mode.

 

Actually it is that the actual recording doesn't proceed. Emby server is running on Server 2012R2 which never goes to sleep. The scheduled task is being created as "DomainName\ComputerName$" for the Run As context which is not valid credentials. That is machine account credentials and are invalid to be used to start or run a task. I am also using NSSM to run Emby as a service using instructions that were provided in this forum years ago.

Link to comment
Share on other sites

Theodore

I run Emby as a service in Windows using nssm to start it on machine startup (i.e., not the built-in service facility), and have had no recording issues such as you describe.

 

I too am running Emby as a service with NSSM using instructions provided in this form years ago. If you have a different way to use it I am all ears (or eyes as the case may be!). The issue I am seeing is that Emby is creating the tasks with the machine account DomainName\MachineName$ which is invalid credentials for running a scheduled task.

Link to comment
Share on other sites

pwhodges

I'll post my nssm configuration tomorrow for you to compare (my server is rebooting with Windows updates right now, and it's midnight so I'm off to bed!).

Link to comment
Share on other sites

Actually it is that the actual recording doesn't proceed. Emby server is running on Server 2012R2 which never goes to sleep. The scheduled task is being created as "DomainName\ComputerName$" for the Run As context which is not valid credentials. That is machine account credentials and are invalid to be used to start or run a task. I am also using NSSM to run Emby as a service using instructions that were provided in this forum years ago.

 

It's due to either the waking and/or the way the task launches embyserver. Neither of these have been looked at from the context of a service, so at this stage we can't say for sure if they will work properly or not.

Link to comment
Share on other sites

pwhodges

Hmm.  On checking I find that (1) nssm is running Emby using the Local System Account; and (2) Emby is scheduling recording tasks using the same ("cass/streamer$" in my case), with the "run only when user is logged on" flag set.  (I also schedule a restart of Emby once a night - that's a legacy from when I was using a built-in Hauppauge tuner which didn't release cleanly - which runs "nssm restart emby" using the "NT AUTHORITY\SYSTEM" account.)

 

But you (like me, now) are using an HDHomeRun tuner - a network device.  By default the Local System Account cannot access the network.  This access can be arranged, but is not considered good practice.  The easiest way to do this is given at the bottom of this page. In the context of my network I have no concerns about this, but you need to make that decision for yourself.  OTOH - now I check, I don't seem to have made this change, so now I'm puzzled that my system works...

 

In the longer term it would be better practice for Emby to be run using a named account with appropriate access permissions (and to use the same account for scheduling recordings) - this would also avoid problems (which I've seen reported) with access to libraries which are on the network.  It might be prudent for the service setup instructions to suggest using the account with which (presumably) the installation was tested before making it a service - it's easy in nssm, as it's just an entry on another tab.  It may be that making this change in your case would resolve the issue.

Link to comment
Share on other sites

Theodore

Hmm.  On checking I find that (1) nssm is running Emby using the Local System Account; and (2) Emby is scheduling recording tasks using the same ("cass/streamer$" in my case), with the "run only when user is logged on" flag set.  (I also schedule a restart of Emby once a night - that's a legacy from when I was using a built-in Hauppauge tuner which didn't release cleanly - which runs "nssm restart emby" using the "NT AUTHORITY\SYSTEM" account.)

 

But you (like me, now) are using an HDHomeRun tuner - a network device.  By default the Local System Account cannot access the network.  This access can be arranged, but is not considered good practice.  The easiest way to do this is given at the bottom of this page. In the context of my network I have no concerns about this, but you need to make that decision for yourself.  OTOH - now I check, I don't seem to have made this change, so now I'm puzzled that my system works...

 

In the longer term it would be better practice for Emby to be run using a named account with appropriate access permissions (and to use the same account for scheduling recordings) - this would also avoid problems (which I've seen reported) with access to libraries which are on the network.  It might be prudent for the service setup instructions to suggest using the account with which (presumably) the installation was tested before making it a service - it's easy in nssm, as it's just an entry on another tab.  It may be that making this change in your case would resolve the issue.

 

Yeah, back in the day Emby did run under a named service - I still have that service in my Services list with that account, it is just disabled - and it ran fine. All media Emby access for me is local to it so I don't have to worry about the Local Service vs. network access you pointed out (thankfully!). It just doesn't make sense that they change things without testing them with what is (was) supported options - like running as a service - then Luke gets dismissive that it isn't actually a problem when it is pointed out. Running a server-style application should be a standard practice and not require logging in to run an application.

Link to comment
Share on other sites

I'm not denying that you're having a problem. I'm saying it's not something we've looked at up to this point, so I can't necessarily say yet what should or shouldn't happen.

Link to comment
Share on other sites

Theodore

I'm not denying that you're having a problem. I'm saying it's not something we've looked at up to this point, so I can't necessarily say yet what should or shouldn't happen.

 

What should happen is pretty straight forward: Emby should start the DVR process to record the program. I can tell you that (one of) the reason it is not doing that is because the Scheduled Task generated is trying to run as the machine account and not a user account or SYSTEM. In the Windows world that is not a valid login account as there is no way to specify credentials to it - so honestly I'm not even sure how you managed to create a task with that credential!

 

I've set the individual tasks to run as the service account I created to run Emby back in v.2 or v.3 something to see if that will work. If so it is a simple matter of scripting a Powershell task to take each task that starts with "Emby*" and reset the run as with the password. I've provided the Powershell command above to create tasks this way but maybe the best way to handle scheduling is to have Emby run it as an internal process rather than creating separate tasks as this would allow the service to run as "NT AUTHORITY\SYSTEM" which eliminates some issues with local permissions. 

 

But let us also breakdown the task:

C:\Users\InstallUser\AppData\Roaming\Emby-Server\system\EmbyServer.exe C:\Users\InstallUser\AppData\Roaming\Emby-Server\system\EmbyServer.dll -service -noautorunwebapp

 

What is going on here? A DLL is NOT an executable that can be scheduled. It is a reference library.

Link to comment
Share on other sites

pwhodges

I can tell you that (one of) the reason it is not doing that is because the Scheduled Task generated is trying to run as the machine account and not a user account or SYSTEM. In the Windows world that is not a valid login account as there is no way to specify credentials to it - so honestly I'm not even sure how you managed to create a task with that credential!

 

You said this before.  However, it is valid (not as as login account, but as one to run a process in), and it is working in my system, and presumably others (as the instructions for setting it up have been public for ages now).

 

Does the Event Log (System or Application, I would check) have anything to indicate the reason for the failure?

Link to comment
Share on other sites

Theodore

 

You said this before.  However, it is valid (not as as login account, but as one to run a process in), and it is working in my system, and presumably others (as the instructions for setting it up have been public for ages now).

 

Does the Event Log (System or Application, I would check) have anything to indicate the reason for the failure?

 

Just an update applied to the ntuser.dat and usrclass.dat files.

 

The command line is OK. 

 

The event viewer on the server is not recording a failure or success at the designated start times. Is there a log in Emby I can export that can help you find the solution to this?

Link to comment
Share on other sites

Theodore

So the machine never woke? Or what was the scenario?

 

The server never goes to sleep. It is a VM that is running 24/7 that only reboots for updates. The task when running with the machine account the task says failed to start because not logged in. When running as the OG service account it says task completed successfully but nothing records.

Link to comment
Share on other sites

Was Emby Server running at the time, or were you relying on the windows scheduled task to launch it?

Link to comment
Share on other sites

Theodore

Was Emby Server running at the time, or were you relying on the windows scheduled task to launch it?

 

Always running, the service is set to start automatically and does.

Link to comment
Share on other sites

Is it possible you've managed to launch multiple simultaneous instances of the server?

2019-10-09 10:54:08.887 Error Main: Error in appHost.Init
	*** Error Report ***
	Version: 4.2.1.0
	Command line: C:\Users\AdminDRL\AppData\Roaming\Emby-Server\system\EmbyServer.dll -service -noautorunwebapp
	Operating system: Microsoft Windows NT 6.2.9200.0
	64-Bit OS: True
	64-Bit Process: True
	User Interactive: True
	Runtime: file:///C:/Users/AdminDRL/AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll
	Processor count: 4
	Program data path: C:\Users\AdminDRL\AppData\Roaming\Emby-Server
	Application directory: C:\Users\AdminDRL\AppData\Roaming\Emby-Server\system
	SQLitePCL.pretty.SQLiteException: Busy: database is locked - PRAGMA journal_mode

When you see this error:

Busy: database is locked

9 times out of 10 that is the reason why.

Link to comment
Share on other sites

Theodore

Is it possible you've managed to launch multiple simultaneous instances of the server?

 

I highly doubt it. There are two entries for Emby Server as a service in the service list but one is disabled and not running since very early in v3 (if not towards the end of v2). There is only one instance running.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...