Jump to content


Photo

Live TV Unable To Record On Schedule

dvr live tv recording

  • Please log in to reply
43 replies to this topic

#1 Theodore OFFLINE  

Theodore

    Advanced Member

  • Members
  • 157 posts
  • Local time: 10:07 AM

Posted 07 October 2019 - 11:31 PM

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.



#2 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 138218 posts
  • Local time: 01:07 PM

Posted 07 October 2019 - 11:33 PM

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.



#3 Theodore OFFLINE  

Theodore

    Advanced Member

  • Members
  • 157 posts
  • Local time: 10:07 AM

Posted 08 October 2019 - 12:08 AM

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


#4 pwhodges OFFLINE  

pwhodges

    Advanced Member

  • Members
  • 267 posts
  • Local time: 06:07 PM
  • LocationOxford, UK

Posted 08 October 2019 - 06:50 AM

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, 08 October 2019 - 06:51 AM.


#5 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 138218 posts
  • Local time: 01:07 PM

Posted 08 October 2019 - 01:07 PM

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

#6 pwhodges OFFLINE  

pwhodges

    Advanced Member

  • Members
  • 267 posts
  • Local time: 06:07 PM
  • LocationOxford, UK

Posted 08 October 2019 - 05:39 PM

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).



#7 Theodore OFFLINE  

Theodore

    Advanced Member

  • Members
  • 157 posts
  • Local time: 10:07 AM

Posted 08 October 2019 - 06:27 PM

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.



#8 Theodore OFFLINE  

Theodore

    Advanced Member

  • Members
  • 157 posts
  • Local time: 10:07 AM

Posted 08 October 2019 - 06:29 PM

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.



#9 pwhodges OFFLINE  

pwhodges

    Advanced Member

  • Members
  • 267 posts
  • Local time: 06:07 PM
  • LocationOxford, UK

Posted 08 October 2019 - 06:51 PM

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!).



#10 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 138218 posts
  • Local time: 01:07 PM

Posted 08 October 2019 - 06:56 PM

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.



#11 pwhodges OFFLINE  

pwhodges

    Advanced Member

  • Members
  • 267 posts
  • Local time: 06:07 PM
  • LocationOxford, UK

Posted 09 October 2019 - 06:18 AM

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.



#12 Theodore OFFLINE  

Theodore

    Advanced Member

  • Members
  • 157 posts
  • Local time: 10:07 AM

Posted 09 October 2019 - 02:22 PM

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.



#13 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 138218 posts
  • Local time: 01:07 PM

Posted 09 October 2019 - 02:26 PM

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.



#14 Theodore OFFLINE  

Theodore

    Advanced Member

  • Members
  • 157 posts
  • Local time: 10:07 AM

Posted 09 October 2019 - 05:23 PM

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.



#15 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 138218 posts
  • Local time: 01:07 PM

Posted 09 October 2019 - 05:59 PM

The command line is OK. 



#16 pwhodges OFFLINE  

pwhodges

    Advanced Member

  • Members
  • 267 posts
  • Local time: 06:07 PM
  • LocationOxford, UK

Posted 09 October 2019 - 07:09 PM



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?



#17 Theodore OFFLINE  

Theodore

    Advanced Member

  • Members
  • 157 posts
  • Local time: 10:07 AM

Posted 09 October 2019 - 10:13 PM

 

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?



#18 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 138218 posts
  • Local time: 01:07 PM

Posted 09 October 2019 - 11:29 PM

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

#19 Theodore OFFLINE  

Theodore

    Advanced Member

  • Members
  • 157 posts
  • Local time: 10:07 AM

Posted 09 October 2019 - 11:33 PM

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.



#20 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 138218 posts
  • Local time: 01:07 PM

Posted 10 October 2019 - 12:16 AM

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







Also tagged with one or more of these keywords: dvr, live tv, recording

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users