Re-adding streams that errored out
Opened this issue · 1 comments
My yta runs with --retry-stream option, for reasons, and occasionally there is a period where the cally to YT made by yta will encounter some error. This temporary issue causes yta to close and hoshinova to list those streams as error on the web interface. I believe there are similar temporary issues with different unknown yta output that can also occur.
Once more advanced yta output handling is implemented, I'd love an option to have hoshinova re-add a queued job that errored out. For now, the workaround is to copy the URL and re-add it manually.
[2023-02-20T10:52:32Z WARN hoshinova::module::recorder] Unknown ytarchive output: 2023/02/20 11:52:32 WARNING: Failed to retrieve data from https://youtu.be/Whc_01aacJY: Get "https://youtu.be/Whc_01aacJY": dial tcp: i/o timeout
[2023-02-20T10:52:33Z WARN hoshinova::module::recorder] Unknown ytarchive output: 2023/02/20 11:52:33 WARNING: Failed to retrieve data from https://youtu.be/p7peFaDfDhY: Get "https://youtu.be/p7peFaDfDhY": dial tcp: i/o timeout
[2023-02-20T10:52:45Z WARN hoshinova::module::recorder] Unknown ytarchive output: 2023/02/20 11:52:45 WARNING: Failed to retrieve data from https://youtu.be/wxlIFhpsRXU: Get "https://youtu.be/wxlIFhpsRXU": dial tcp: i/o timeout
[2023-02-20T10:52:45Z WARN hoshinova::module::recorder] Unknown ytarchive output: 2023/02/20 11:52:45 WARNING: Failed to retrieve data from https://youtu.be/bBNWNfckUi4: Get "https://youtu.be/bBNWNfckUi4": dial tcp: i/o timeout
[2023-02-20T10:52:50Z WARN hoshinova::module::recorder] Unknown ytarchive output: 2023/02/20 11:52:50 WARNING: Failed to retrieve data from https://youtu.be/TlnRKz5D1CU: Get "https://youtu.be/TlnRKz5D1CU": dial tcp: i/o timeout
[2023-02-20T10:52:59Z WARN hoshinova::module::recorder] Unknown ytarchive output: 2023/02/20 11:52:59 WARNING: Failed to retrieve data from https://youtu.be/Jm3oo8dYxIM: Get "https://youtu.be/Jm3oo8dYxIM": dial tcp: i/o timeout
[2023-02-20T10:52:59Z WARN hoshinova::module::recorder] Unknown ytarchive output: 2023/02/20 11:52:59 WARNING: Failed to retrieve data from https://youtu.be/mwvzktlABrk: Get "https://youtu.be/mwvzktlABrk": dial tcp: i/o timeout
[2023-02-20T10:53:03Z WARN hoshinova::module::recorder] Unknown ytarchive output: 2023/02/20 11:53:03 WARNING: Failed to retrieve data from https://youtu.be/OZAWyFf_kak: Get "https://youtu.be/OZAWyFf_kak": dial tcp: i/o timeout
[2023-02-20T10:53:05Z WARN hoshinova::module::recorder] Unknown ytarchive output: 2023/02/20 11:53:05 WARNING: Failed to retrieve data from https://youtu.be/t0en1SAPLL8: Get "https://youtu.be/t0en1SAPLL8": dial tcp: i/o timeout
I second this. Here is the scenario I encountered.
I am monitoring a channel to capture all its live steams (filter on a specific keyword).
When the channel announces its live earlier, it is detected on the rss feed and tries to capture it - which fails and mark it as errored.
It never retries it ever again and I end up missing the record altogether...
Since I am only using Hoshinova as a monitoring tool, this defeats the purpose with channels announcing their streams earlier 😥
2 solutions to handle that would be to:
- Detect and prevent streams from RSS that have not started yet (thus ensuring never starting the capture before it becomes available) - but this solution would not resolve the issue this topic mentions.
- Allow to set up a retry mechanism on errored entries?
EDIT: It seems that the channel I follow announced its stream and this time it was marked as Waiting (null)
and managed to pick it up when it started. So my guess is that previously the first time it tried to access it failed for unknown reason and since it was stuck in Error
mode, it never retried it.
A retry mechanism for errored streams would be great for that case!