Eating resources and stalling

[holmgrendev]

Describe the bug

m3u-editor stalls when trying to sync, eating all the systems resources and a manual intervention is needed to stop it.

m3u- editor is not accessible during this and no other container is reachable, not even the virtual machine is accessible.

To Reproduce

Steps to reproduce the behavior:

1. Schedule sync of a playlist once a day at 01:00

Expected behavior

Playlist should sync and then go idle

Actual behavior

Playlist starts to sync, eating almost all resources, while nothing is happening and fails(?) sync after manual intervention.

Notifications says:

• "Error processing "x EPG"" <- due to issues with the provider, not m3u-editor.
• "Playlist Synced"
• "Series Sync Completed".

See screenshot for all notifications from that sync

To stop this behavior, a manual intervention such as this has to be done:

• Rebooting virtual machine or
• restarting Docker container or
• Increasing RAM

Screenshots

• After first RAM-hogging i rebooted the machine.
• During second hogging, i increased the ram
• Third, probably just went on for 1-2 hours
• Fourth, (See last 24 hours for detailed) I first increased the ram, it went down. After decrease, it went up again. Tried increasing again and it went down permanent (for now).

Last week:

Last 24 hours:

docker-compose.yml contents

services:
  m3u-editor:
    image: sparkison/m3u-editor:latest
    container_name: m3u-editor
    restart: always

    environment:
      - TZ=City/Country   # Redacted for this bug report
      - APP_URL=http://example.com # Redacted for this bug report

    volumes:
      - /path/to/data:/var/www/config   # /path/to/data redacted for this bug report

    ports:
      - 36400:36400

Container/Host Logs

No logs except the start up logs that occurred after this issue.

I checked the logs before restart and it said something like this after increasing the RAM:

Series sync error after HH:ii:ss

No stack trace or anything, everything else seemed normal

Additional context

I think it started when the provider started to have issues with the EPG

Version: v0.8.19
Docker: 29.1.3

[sparkison]

What version are you running? We had pushed some series sync updates yesterday that might help with this (should be on 0.8.25-dev or later)

@Serph91P, any other ideas? I don't use series sync that much other than testing, but you've been working on optimizing the series sync so wondering if you have any insight...

[sparkison]

@holmgrendev, as a quick fix to your issue you can disable series sync. It's the series sync, not the playlist sync itself, that's causing your issues.

[Serph91P]

What version are you running? We had pushed some series sync updates yesterday that might help with this (should be on 0.8.25-dev or later)

@Serph91P, any other ideas? I don't use series sync that much other than testing, but you've been working on optimizing the series sync so wondering if you have any insight...

Just checked this myself. For me local on my dev machine it seems to be Postgres? Got the all-in-one running.

@holmgrendev Can you please confirm you got the all-in-one running? Because your attached docker compose seems to be incomplete? In regard to the docker compose files provided: https://github.com/sparkison/m3u-editor/blob/master/docker-compose.aio.yml . How Many series do you have or want to sync?

[Serph91P]

What version are you running? We had pushed some series sync updates yesterday that might help with this (should be on 0.8.25-dev or later)

@Serph91P, any other ideas? I don't use series sync that much other than testing, but you've been working on optimizing the series sync so wondering if you have any insight...

Found the issue it is cleanupOrphaned() Which got called for every series instead once at the end of the sync process.

[Serph91P]

@sparkison opened another pull request for this issue: #592

@holmgrendev FYI

[djvanes010]

Having this problems also. FYI

[holmgrendev]

@sparkison
Using 0.8.19 but I'm going to try the dev-branch.

@Serph91P
Im using the compose example from here:
https://sparkison.github.io/m3u-editor-docs/docs/about/getting-started/#-docker-compose

I see that the PR was merged and a new image was pushed to docker so lets try it tonight.

Thanks guys!

[sparkison]

I see that the PR was merged and a new image was pushed to docker so lets try it tonight.

Thanks guys!

that sounds good! Let us know how it goes 🤞

[holmgrendev]

So, its still behaving the same.
version: v0.8.26-dev

Everything in the logs seems normal except on a few places.

2025-12-31 01:17:01 App\Jobs\ProcessM3uImportSeriesEpisodes ........ RUNNING
  2025-12-31 01:17:02 App\Jobs\ProcessM3uImportSeriesEpisodes ........ 1s DONE
  2025-12-31 01:17:02 App\Jobs\ProcessM3uImportSeriesEpisodes ........ RUNNING
2025-12-31 02:02:55,040 INFO exited: websocket (exit status 0; expected)
2025-12-31 02:02:56,049 INFO spawned: 'websocket' with pid 2473
  2025-12-31 02:02:54 App\Jobs\ProcessM3uImportSeriesEpisodes ... 45m 52s FAIL
  2025-12-31 01:17:08 App\Jobs\SyncSeriesStrmFiles ................... 9s DONE
  2025-12-31 01:17:08 App\Jobs\SyncSeriesStrmFiles ................... RUNNING

   INFO  Starting server on 0.0.0.0:36800 (localhost).  

2025-12-31 02:02:57,983 INFO success: websocket entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
  2025-12-31 02:02:57 App\Jobs\ProcessM3uImportSeriesEpisodes ........ RUNNING
  2025-12-31 02:02:57 App\Jobs\SyncSeriesStrmFiles ................... RUNNING

Logs when i increased RAM and made the stalling "go away"

2025-12-31 02:21:16 App\Jobs\ProcessM3uImportSeriesEpisodes ........ RUNNING
  2025-12-31 02:21:17 App\Jobs\ProcessM3uImportSeriesEpisodes ........ 1s DONE
  2025-12-31 02:21:17 App\Jobs\ProcessM3uImportSeriesEpisodes ........ RUNNING

In AbstractConnection.php line 144:
                                                                     
  Error while reading line from the server. [tcp://localhost:36790]  
                                                                     

  2025-12-31 10:20:36 App\Jobs\ProcessM3uImportSeriesEpisodes  7h 59m 19s FAIL
  2025-12-31 10:20:38 Filament\Notifications\BroadcastNotification ... RUNNING

[Serph91P]

So, its still behaving the same. version: v0.8.26-dev

Everything in the logs seems normal except on a few places.

2025-12-31 01:17:01 App\Jobs\ProcessM3uImportSeriesEpisodes ........ RUNNING
  2025-12-31 01:17:02 App\Jobs\ProcessM3uImportSeriesEpisodes ........ 1s DONE
  2025-12-31 01:17:02 App\Jobs\ProcessM3uImportSeriesEpisodes ........ RUNNING
2025-12-31 02:02:55,040 INFO exited: websocket (exit status 0; expected)
2025-12-31 02:02:56,049 INFO spawned: 'websocket' with pid 2473
  2025-12-31 02:02:54 App\Jobs\ProcessM3uImportSeriesEpisodes ... 45m 52s FAIL
  2025-12-31 01:17:08 App\Jobs\SyncSeriesStrmFiles ................... 9s DONE
  2025-12-31 01:17:08 App\Jobs\SyncSeriesStrmFiles ................... RUNNING

   INFO  Starting server on 0.0.0.0:36800 (localhost).  

2025-12-31 02:02:57,983 INFO success: websocket entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
  2025-12-31 02:02:57 App\Jobs\ProcessM3uImportSeriesEpisodes ........ RUNNING
  2025-12-31 02:02:57 App\Jobs\SyncSeriesStrmFiles ................... RUNNING

Logs when i increased RAM and made the stalling "go away"

2025-12-31 02:21:16 App\Jobs\ProcessM3uImportSeriesEpisodes ........ RUNNING
  2025-12-31 02:21:17 App\Jobs\ProcessM3uImportSeriesEpisodes ........ 1s DONE
  2025-12-31 02:21:17 App\Jobs\ProcessM3uImportSeriesEpisodes ........ RUNNING

In AbstractConnection.php line 144:
                                                                     
  Error while reading line from the server. [tcp://localhost:36790]  
                                                                     

  2025-12-31 10:20:36 App\Jobs\ProcessM3uImportSeriesEpisodes  7h 59m 19s FAIL
  2025-12-31 10:20:38 Filament\Notifications\BroadcastNotification ... RUNNING

@sparkison would need to correct me on this but aren't those in the repository the go to compose files? Yeah, the documentation needs updating 😄

@holmgrendev let me check this again maybe something is still getting triggered for all the requests.