Error: search returned no videos occuring multiple times per video, runs quota up
QueenLinuxGlitch opened this issue · 6 comments
Using latest version,
In a lot of videos, the following log lines will appear
2023/09/03 18:00:21 INFO Video ID not found. Searching for video on YouTube... device="Living Room TV"
2023/09/03 18:00:21 ERROR Failed to find video on YouTube. device="Living Room TV" error="search returned no videos"
And it will continue to occur roughly every minute, never resolving the video.
I was told that this was more likely related to buffering, but this has been shown to not be correct, as regardless of buffer status this can occur, although it is more likely to occur on long (>30m) videos
Almost Every day now, when using youtube normally with CastSponsorSkip running, I am more likely to hit my Quota cap, due to all the requests that never resolve, leaving the application completely useless until quota reset the next day
2023/09/03 18:37:32 INFO Video ID not found. Searching for video on YouTube... device="Living Room TV"
2023/09/03 18:37:32 ERROR Failed to find video on YouTube. device="Living Room TV" error="search returned no videos"
2023/09/03 18:38:32 INFO Video ID not found. Searching for video on YouTube... device="Living Room TV"
2023/09/03 18:38:33 ERROR Failed to find video on YouTube. device="Living Room TV" error="search returned no videos"
2023/09/03 18:39:33 INFO Video ID not found. Searching for video on YouTube... device="Living Room TV"
2023/09/03 18:39:33 ERROR Failed to find video on YouTube. device="Living Room TV" error="search returned no videos"
2023/09/03 18:40:33 INFO Video ID not found. Searching for video on YouTube... device="Living Room TV"
2023/09/03 18:40:33 ERROR Failed to find video on YouTube. device="Living Room TV" error="search returned no videos"
2023/09/03 18:41:33 INFO Video ID not found. Searching for video on YouTube... device="Living Room TV"
2023/09/03 18:41:34 ERROR Failed to find video on YouTube. device="Living Room TV" error="search returned no videos"
2023/09/03 18:42:34 INFO Video ID not found. Searching for video on YouTube... device="Living Room TV"
2023/09/03 18:42:34 ERROR Failed to find video on YouTube. device="Living Room TV" error="search returned no videos"
2023/09/03 18:43:34 INFO Video ID not found. Searching for video on YouTube... device="Living Room TV"
2023/09/03 18:43:34 ERROR Failed to find video on YouTube. device="Living Room TV" error="search returned no videos"
2023/09/03 18:44:34 INFO Video ID not found. Searching for video on YouTube... device="Living Room TV"
Same video
2023/09/02 01:32:07 INFO Video ID not found. Searching for video on YouTube... device="Bedroom TV"
2023/09/02 01:40:39 ERROR Failed to find video on YouTube. device="Bedroom TV" error="googleapi: Error 403: The request cannot be completed because you have exceeded your <a href="/youtube/v3/getting-started#quota">quota., quotaExceeded"
Error message when quota is exceeded
I just realized this is currently being worked on, I'm here to troubleshoot if needed
The bigger issue, in my eyes, is why would the query ever return no videos in the first place. The video is on youtube, case in point, the video id definitely exists
Yeah I have a fix for that which hasn't yet been released. I'll go ahead and do that! I agree, though, that search should always return the current video. I saw similar issues in sponsorblockcast, which I referenced to build the search logic. Basically, if it can't find a video ID directly in the Cast device metadata, it'll perform the following search on YouTube:
"CHANNEL"+intitle:"TITLE"
which doesn't seem to always return results. I haven't gotten a chance yet, but I have a device that sometimes does this, so I'd like to dig into the metadata and see if there's a more reliable way to find the currently playing video. I'll keep you posted on that, but let me go ahead release that fix for now!
Testing new release now, btw want to let you know good work overall, you've been very responsive, and a personal thank you
Oh thanks! I really appreciate all of your great feedback. It's helped to get this stable enough to justify a v1.0.0 release...once I have these issues fixed 🙂
continuing in #18