Workaround: customize UpNext / Next Episode prompt timing in Emby Web

[lolotux 4]

Hi,

I found a workaround to change when the “Next Episode / Up Next” prompt appears in Emby Web.

Tested on Emby 4.9.5.0.

File:
 /opt/emby-server/system/dashboard-ui/videoosd/videoosd.js

Original logic uses:
 30 / 35 / 40 seconds before the end,
depending on episode duration.

I changed it to trigger at 96% of playback instead, so the prompt appears when about 4% of the episode remains.

Patch idea:

1. Backup the file.

2. Replace the fallback timing logic:

 runtimeTicks-1e3*(fiftyMinuteTicks<=runtimeTicks?40:fortyMinuteTicks<=runtimeTicks?35:30)*1e4

with:

 runtimeTicks*.96

3. Optional but important:
Emby may use CreditsStart markers when available, so I also forced creditsInfo to 0 in the UpNext calculation to always use the percentage-based trigger.

4. Restart Emby.

5. Clear/reload the browser cache for:
 /web/videoosd/videoosd.js?v=4.9.5.0

In Chromium/Chrome DevTools console:

fetch('/web/videoosd/videoosd.js?v=4.9.5.0', {cache:'reload'})

Important notes:
- This is not an official setting.
- It will probably be overwritten by Emby updates.
- Backup before modifying.
- A proper UI setting would still be much better.

Result:
The UpNext prompt now appears around 96% of the episode instead of the hardcoded 30/35/40 seconds.

[lolotux 4]

12 hours ago, lolotux said:

Hi,

I found a workaround to change when the “Next Episode / Up Next” prompt appears in Emby Web.

Tested on Emby 4.9.5.0.

File:
 /opt/emby-server/system/dashboard-ui/videoosd/videoosd.js

Original logic uses:
 30 / 35 / 40 seconds before the end,
depending on episode duration.

I changed it to trigger at 96% of playback instead, so the prompt appears when about 4% of the episode remains.

Patch idea:

1. Backup the file.

2. Replace the fallback timing logic:

 runtimeTicks-1e3*(fiftyMinuteTicks<=runtimeTicks?40:fortyMinuteTicks<=runtimeTicks?35:30)*1e4

with:

 runtimeTicks*.96

3. Optional but important:
Emby may use CreditsStart markers when available, so I also forced creditsInfo to 0 in the UpNext calculation to always use the percentage-based trigger.

4. Restart Emby.

5. Clear/reload the browser cache for:
 /web/videoosd/videoosd.js?v=4.9.5.0

In Chromium/Chrome DevTools console:

fetch('/web/videoosd/videoosd.js?v=4.9.5.0', {cache:'reload'})

Important notes:
- This is not an official setting.
- It will probably be overwritten by Emby updates.
- Backup before modifying.
- A proper UI setting would still be much better.

Result:
The UpNext prompt now appears around 96% of the episode instead of the hardcoded 30/35/40 seconds.

Here is an Howto

 

HowTo - Emby Web: show the Next Episode prompt at 96% playback

Version: 2026-07-05

Tested on: Debian 12, Emby Web 4.9.5.0

1. Goal

This HowTo changes when the Next Episode / Up Next prompt appears in Emby Web.

The target behavior is:

Show the prompt when 96% of the episode has been played.

In other words, the prompt appears when about 4% of the episode remains.

The native Emby Web behavior uses a hardcoded fallback of roughly 30 / 35 / 40 seconds before the end, depending on the episode duration. It may also use a CreditsStart marker when one is available.

This workaround replaces that behavior with a percentage-based trigger.

2. File involved

/opt/emby-server/system/dashboard-ui/videoosd/videoosd.js

This is the Emby Web video OSD JavaScript file.

3. Backup the original file

Create a backup directory and copy the current JavaScript file before changing anything.

sudo mkdir -p /root/backup_emby_ui
sudo cp -a /opt/emby-server/system/dashboard-ui/videoosd/videoosd.js /root/backup_emby_ui/videoosd.js.BAK_$(date +%Y%m%d_%H%M%S)

4. Apply the 96% patch

The patch does two things:

1. It ignores the CreditsStart marker for this UpNext calculation by forcing creditsInfo=0.

2. It replaces the native fixed timing logic with runtimeTicks*.96.

The command below works whether the file still contains the native 40/35/30 values or an older test using 120/120/120.

sudo python3 - <<'PY'
from pathlib import Path
import re

p = Path('/opt/emby-server/system/dashboard-ui/videoosd/videoosd.js')
s = p.read_text()

s = s.replace(
    'creditsInfo=(null==creditsInfo?void 0:creditsInfo.start)||0',
    'creditsInfo=0'
)

pattern = r'runtimeTicks-1e3\*\(fiftyMinuteTicks<=runtimeTicks\?\d+:fortyMinuteTicks<=runtimeTicks\?\d+:\d+\)\*1e4'
s2 = re.sub(pattern, 'runtimeTicks*.96', s, count=1)

if s2 == s and 'runtimeTicks*.96' not in s:
    raise SystemExit('UpNext timing expression not found. Please check videoosd.js manually.')

p.write_text(s2)
print('OK UpNext 96 percent patch applied')
PY

5. Restart Emby

Restart the Emby server so it serves the modified file.

sudo systemctl restart emby-server

6. Verify server-side content

This command bypasses the browser cache by adding a random query parameter.

curl -s 'http://debian12:8096/web/videoosd/videoosd.js?check='$(date +%s) \
  | grep -oE 'creditsInfo=0|runtimeTicks\*\.96|runtimeTicks-1e3\*\(fiftyMinuteTicks<=runtimeTicks\?[0-9]+:fortyMinuteTicks<=runtimeTicks\?[0-9]+:[0-9]+\)\*1e4'

Expected result:

creditsInfo=0
runtimeTicks*.96

If the old runtimeTicks-1e3*(...) expression still appears, the patch did not apply correctly.

7. Force the browser cache to reload

Important trap observed during testing: Chromium may keep serving an old cached file for this exact versioned URL:

/web/videoosd/videoosd.js?v=4.9.5.0

Open Emby Web in the browser, open DevTools, go to the Console, and run:

fetch('/web/videoosd/videoosd.js?v=4.9.5.0', {cache:'reload'})
  .then(r => r.text())
  .then(t => console.log(
    'PCT96=', t.includes('runtimeTicks*.96'),
    'CREDITS0=', t.includes('creditsInfo=0'),
    'HAS_NATIVE=', /fiftyMinuteTicks<=runtimeTicks\?\d+:fortyMinuteTicks<=runtimeTicks\?\d+:\d+/.test(t)
  ));

Expected console result:

PCT96= true CREDITS0= true HAS_NATIVE= false

Then close and reopen the Emby tab, or use:

Ctrl+F5

If your Emby Web version is different, adapt the v=4.9.5.0 value to the version actually shown by your browser.

8. What 0.96 means in practice

runtimeTicks*.96 means that the prompt appears after 96% of the episode runtime.

Episode duration	Prompt appears with about
40 min	1 min 36 sec remaining
50 min	2 min remaining
60 min	2 min 24 sec remaining

Formula:

remaining time = total duration * 4%

9. Rollback

Restore the backup file, restart Emby, and force the browser cache to reload again.

sudo cp -a /root/backup_emby_ui/videoosd.js.BAK_YYYYMMDD_HHMMSS /opt/emby-server/system/dashboard-ui/videoosd/videoosd.js
sudo systemctl restart emby-server

Then rerun the browser fetch(..., {cache:'reload'}) command from section 7.

10. Important notes

Do not delete these directories for this issue:

/var/lib/emby/metadata
/var/lib/emby/cache

The issue is not caused by Emby metadata or image cache. The relevant parts are:

videoosd.js
browser cache for videoosd.js?v=...

Also note:

• This is not an official Emby setting.
• Emby updates may overwrite videoosd.js.
• Always keep a backup.
• A proper official UI setting for the UpNext prompt timing would be better.
• creditsInfo.start corresponds to the CreditsStart marker. The patch forces creditsInfo=0 so the percentage-based trigger is always used.

11. Short forum summary

Tested workaround for Emby Web 4.9.5.0:

The UpNext / Next Episode prompt timing is handled in:
/opt/emby-server/system/dashboard-ui/videoosd/videoosd.js

The native fallback uses hardcoded 30/35/40 seconds before the end.
I replaced that fallback with:

runtimeTicks*.96

This makes the prompt appear at 96% playback, so about 4% of the episode remains.

I also forced creditsInfo=0 in the UpNext calculation so CreditsStart markers do not override the percentage-based trigger.

After changing the file:
- restart Emby
- force browser cache reload for /web/videoosd/videoosd.js?v=4.9.5.0

This is only a workaround and may be overwritten by Emby updates.
An official UI option would still be much better.

 

Edited 12 hours ago by lolotux

[ebr 16465]

Hi.  I imagine this will be too aggressive.  In my experience, 45-55 minute episodes do not have 2+ minutes of credits.

One thing for readers to be aware of is that modifying the source components like this will get overwritten on each update.

You could just create end credit markers using one of the plugins instead.

[lolotux 4]

5 hours ago, ebr said:

Hi.  I imagine this will be too aggressive.  In my experience, 45-55 minute episodes do not have 2+ minutes of credits.

One thing for readers to be aware of is that modifying the source components like this will get overwritten on each update.

You could just create end credit markers using one of the plugins instead.

Fortunately, the percentage is configurable.........

Rome: 2 minutes out of 50 minutes = 96%

Edited 45 minutes ago by lolotux

[lolotux 4]

5 hours ago, ebr said:

Hi.  I imagine this will be too aggressive.  In my experience, 45-55 minute episodes do not have 2+ minutes of credits.

One thing for readers to be aware of is that modifying the source components like this will get overwritten on each update.

You could just create end credit markers using one of the plugins instead.

Have you read all my trick?
"This is only a workaround and may be overwritten by Emby updates.
An official UI option would still be much bett"
....