Yeah...this isn't a big deal since you can assign any gracenote id with SLM/PLM (which I have done for a long time now).
@bnhf I think I’m ready to wave the white flag on this one and yield to experience on the Docker persistence front. Would you mind creating the requisite PR / guidance for folks? Clearly this isn’t going to be solved by my modest attempts to cleanup after Chrome. 
1 Like
I understand, and had similar feelings before switching to the more targeted approach to making Chrome data persistent with CC4C.
My theory (and it is just a theory), is that Chrome is not particularly well suited to the abrupt nature of container restarts. And, I believe this leads to the corruption of cache or other Chrome temporary files. Since these files are not necessary to hold over between restarts/reboots, I switched to making only those Chrome items that we do want to maintain persistent.
The only other thing I'll mention as reference point, is that this issue with prismcast_data becoming corrupted only seems to have reared its ugly head again recently -- with PrismCast versions post 1.3.0. I only mention this in case there are any changes between 1.2.x and 1.3.x that you think are worth looking at in this regard.
We cross-posted there. We'll need to have a discussion about how to logically separate the JSON and log files from the Chrome data. Shall we take that to GitHub, or PMs?
I am on Unraid and, for updating, it uses what you see at bnhf/prismcast - Docker Image. Therefore, I'm on the "latest", and stuck back on V1.1.0.
The ":test" release is V1.3.3, I guess. None of the intervening releases look available to me. What is the plan? Should I go ahead and update to ":test" or will it be changed to ":latest" at some point soon?
Manually updating a container is not something I do on Unraid, and I want to avoid that.
I was only involved hosting the Docker container at the start. It's now hosted at ghcr.io/hjdhjd/prismcast:latest
We cross-posted there. We'll need to have a discussion about how to logically separate the JSON and log files from the Chrome data. Shall we take that to GitHub, or PMs?
Let’s take this one to PMs…I do want to work through it a bit. And I had the same thought about the 1.2.x vs 1.3.x versions and do have an idea of where I might look…
That worked. Thanks.
1 Like
I was able to create some channels on DTV and Freecast by using fullscreenAPI-sites needing javascript fullscreen
DTV:
NHL network
Freecast:
World Fishing Network
Sony Movies
HDNet
Sportman Channel
Axis
@bnhf @Jean0987654321 I’ve got one more update coming in short order that might do the trick. Let’s try that and see if we can avoid going the yucky route. Thanks both for your help in testing / working this one.
@hjd I noticed with native mode it uses avc in mp4. In the mediarecorder docs it mentions being able to use some hevc formats..
Is there any way hevc native recording could be implemented or is that a restriction of puppeteer-stream?
Thanks for updating - unfortunately, I am seeing the same problems with 1.3.3 in the short time that I have been testing, but I am definitely available to test further updates - today I read others reporting similar issues, perhaps described a little bit differently, but I think we are all seeing the same thing
Edit: after posting this, I changed the setting for resolution from 720p to 1080p and restarted the docker and I have not yet seen a glitch for several minutes - normally, I would have seen a problem by now - maybe this is a clue (or a coincidence) - I will update later…
Edit2: it took a long time but finally saw the problem
@bnhf and @Jean0987654321 give v1.3.4 a go and see if that helps. It should give Chrome plenty of grace echoing more of the 1.2.x behavior.
1 Like
@hjd I noticed with native mode it uses avc in mp4. In the mediarecorder docs it mentions being able to use some hevc formats..
Is there any way hevc native recording could be implemented or is that a restriction of puppeteer-stream?
It’s more of a soft restriction than a hard limit, so it’s workable.
I’d love to make that the default. I’ve experimented with it and a number of similar approaches and while it’s enticing, it isn’t realistic right now. The instability is coming from Chrome. It’s pretty clear the Chrome/Chromium team isn’t exercising that code path very often for this kind of use.
In practice, Chrome becomes unstable and will lock up entirely after roughly 15–20 minutes when running in those modes.
I’ve left the native path in place because I do want to default to it eventually. At the moment, though, it’s not feasible if you want anything close to a reliable experience.
Rest assured, this is firmly on my radar.
1 Like
Awesome that’s great to here it’s on the radar.
Has anyone reported the encoder issues to the Chrome team?
Also, I can confirm that on Windows Chrome is doubling the requested bit rate, I changed it to 4 and it's now encoding at 8.
I’ve been running this headless on Windows 11 as a service and mentioned previously that starting with update 1.3.0 I would experience video becoming either very choppy or just stuck after a couple minutes and then it would start playing really fast to catch up to where it’s supposed to be, all-the-while the audio kept rolling along normally.
With the latest update to 1.3.4 I still get this issue, although not quite as frequently as before. But what I did find is that if I don’t run it headless and have a chrome window and command prompt window open minimized on the desktop, everything seems to work just fine. I let it go for a good 15 minutes and maybe there were 2 brief buffering hiccups that lasted all of but a couple seconds but it seems much smoother running it this way. Wonder why that is?
Also, another question. My PrismCast is using FFMPEG that Channels DVR is using. I also have FFMPEG installed in a different directory. I like to download the latest updates from gyan.dev Is there a way you can change what FFMPEG PrismCast uses?
(post deleted by author)
Also, another question. My PrismCast is using FFMPEG that Channels DVR is using. I also have FFMPEG installed in a different directory. I like to download the latest updates from gyan.dev Is there a way you can change what FFMPEG PrismCast uses?
I’d point you to the documentation and the configuration options in the PrismCast web UI. However, this is likely unrelated to what you’re seeing. FFmpeg plays a very small role here and does very little in this part of the pipeline. That said, feel free to experiment — the settings are there for that purpose. 
Windows should work, others and yourself have reported it does, but I’m not directly supporting it myself. I’m relying on the community to help sort out platform-specific issues - PrismCast was, and remains, macOS-first, but not macOS-only. That said, I’m very interested in anecdotal reports and especially true A/B testing results as I continue refining PrismCast. As I’ve mentioned before, it’s still early days.
If you can eliminate variables, run 1.2.1, verify you have no issues (pick a channel, record it for two hours) and then do the same thing with the latest PrismCast release, it’ll be helpful for me as I continue to evolve PrismCast.
A broader community note and request: before posting, please take a moment to review the documentation and the PrismCast configuration options in the webUI as well as the hundreds of prior posts (the in-thread search is quite solid). I’ve revised the PrismCast webUI documentation substantially and will continue to do so. Many of the most common questions are answered there, which helps keep this already busy thread easier to follow. There is also a Help tab in the webUI that addresses several recurring items I’ve seen come up here.
I’m appreciative of the response PrismCast has received. It’s a side project that I rely on every day in my own household…it’s essential equipment for me. I want to provide as much support as I reasonably can, but it’s going to take the community to help address everything across different platforms and environments. This project started, and remains, a gift to the Channels DVR community.
I want to hear about issues, feature requests, and ideas. As I’ve said previously: respectful feedback is always welcome; entitlement is not. I’ll continue to evolve the roadmap for PrismCast over time, but let’s be clear: I write opinionated software, and my priorities may not always align with yours.
4 Likes