One thing that I noticed when I upgraded to V5 was the presence of an XML file with each recorded TS.
What I've only just discovered is that MCEBuddy reads that XML data.
The problem that I was trying to solve was to prevent recordings from the ABC being processed through Comskip. With NextPVR V4 I had set up a conversion task in MCDBuddy that took all recordings from NextPVR, ran Comskip over it, then transcoded it to X264 MP4 for insertion into my Plex Media Server's file tree. The problem with at is that Comskip is done to all recordings with a common .ini file which sometimes resulted in bits of programs going missing - particularly from ABC and SBS recordings.
I had been toying with the PostProcessing.BAT in NextPVR scripts area but I wasn't getting an elegant solution.
The discovery that MCE buddy reads the XML file means that I can now have multiple conversion tasks in MCEBuddy which are tailored to different channels, without the need for PostProcessing.bat .
For the ABC task I set the Channel Name match to ABC* so that it will process any recording with a channel that begins with ABC, then set Remove ads to "no", so from now on any ABC recordings just get transcoded.
This now lends itself to having conversion tasks with different comskip.ini profiles to account for the difference between some channels e.g SBS and the other commercial stations.
I now have a conversion task for SBS with the channel match set to SBS* and the Remove ads is set to Comskip and the Comskip INI line points to an .ini file that is tailored to SBS.
The last task is the original that I was using with V4 but which now has the channel match set to *;~ABC*;~SBS* {all channels Except ABC or SBS} with comskip on and the comskip.ini for the commercial stations.
I'm now in the process of tweaking the ini files to get better results for SBS and the other stations. The Comskip Tuning Guide is a great help. The discovery that there is a -w debug screen option is great news as well as the option of running comskip with a previously generated [recording title].txt file that allows you to manually adjust the ad-breaks in the show.
I realise that this post is more about MCEBuddy and Comskip than NextPVR, but I thought this might help the community of NextPVR users. I've struggled to find coherent information to make things work the way I wanted it to. The fact that MCEBuddy reads the V5 xml files was an accidental discovery, and the fact that the Channel Name Match field reads the <Channel> in the xml was all new to me. The syntax for the matching was derived from the MCEBuddy advanced doco that was explaining how to match show names.
The last part of my process before inserting into plex is to trim off the Pre and Post padding from the recordings so as to just have the program from start to finish in the Plex server. Currently this is mandraulic, using VLC with a time.lua add-on to show the elapsed time on the screen to determine the Stime and Ftime to type into a batch file that has an ffmpeg line with -ss and -to parameters. I'm thinking that I might be able to use the Comskip .txt file option to generate an edl file that I can use to trim off the pre and post padding, but I don't think this reduces the manual workload very much other than saving me having to scribble down the times while reviewing in VLC in order to type them into the Trim.Bat. I know that MCEBuddy has got Start and End trim options in the conversion task, but you need to review the completed file before you can trim it.
If anyone has any suggestions on how to automate the removal of pre and post padding , I'm all ears .
Often Kodi won't even play NextPVR recordings, and when it does lately, it stutters to the point of being unusable. I'm accessing recordings via a wired LAN. Here are some highlights from the full log when I encountered a state where a file wouldn't play at all. Thanks for any guidance.
hi im trying to setup nextpvr on emby and read that i need to donate through paypal to use which i did. i also read that i need to confirm payment in the web app but cant find where to do that
I have multiple playlists as sources for NextPVR. One I call "local.m3u" this one is all fixed streams and I can add an additional single fixed stream to it easily. It sits on the same Pi that is running NextPVR and is made available to NextPVR via Apache2 using 'localhost'.
If I customize a channel number like say I put ch 40 "XYZ TV" from this list at channel 10, then later I add a channel to this list, then click "update", all customizations to XYZ TV's name and Channel number are lost. Not only are they lost to that one channel 'XYZ TV' but to ALL channels I have customized on that m3u source! Names are restored to original and new channel (not even the original channel number) is assigned. It is actually quite crazy behavior , well beyond unexpected but absolutely illogical.
Maybe there is a way around this?
Isn't this what a database is for, keeping tack of original name and new overwritten name?
It like so many other things in most of these darn PVR back-ends make no sense whatsoever.
I am working from a couple of different playlists, each with its own xml guide data. It would not surprise me to find that a channel or two display the wrong icons , however I have many channels displaying the wrong icons. Which icon does NextPVR use the icon in the m3u or in the xml? I believe in some cases they are defined in both.
One of the sources that often displays the wrong icons is using Xumo TV by way of Cabernet , although I have seen the same issue with other sources and it really depends on the playlists I load. The same source is not consistently affected.
Also I have one source that is an HDHomerun tuner and get guide data by way of zap2xml These channels mostly have icons defined in the xml but seem to not be used even though the links to the icons are valid and tested.
hello
i am having issues with one of my systems where i am getting choppy video and lip-sync of the audio. it is happening on my testing within 6:30 to 7:00 pm on all channels.
I have tried with the vpn and without. my cpu usage hovers between 15 to 40 percent.
Any info as to why this is happening is much appreciated. logs enclosed.
thank you
bruce
Is it possible to keep the computer awake during remotely viewing a recording, similar to the way the system is kept awake during recording?
Specifically, the scenario I am running into is that I have a Sony android TV on which I installed Kodi. I have it configured to wake on LAN my Windows 11 HTPC, which has NextPVR installed on it. It works great, the computer remotely turns on and I can access the recordings and watch them. The issue is that my HTPC is set to sleep after 5 minutes of inactivity. The remove viewing of the recording doesn't keep the HTPC awake, so after watching the recording for 5 minutes it freezes because the HTPC goes to sleep. I know that I can easily work around the issue by increase my sleep timer on my HTPC, so it doesn't go to sleep in 5 minutes. However, I do like having it set at 5 minutes as that allows it to go to sleep after finishing recordings and doing the nightly updates of the EPG. I was really hoping that was a way to keep the system awake during the remote access of NextPVR.
I tried the latest build ( v5.2.7.2204106) under Debian Bullseye.
It improved the overall reception of the EPG. Before I had to run the EPG scanner several times with extended scan time to somewhat randomly complete all EPG entries for all TV stations. Now, I only need to run the EPG once with the default 60 sec scan.
That a great improvement!!
One issue is still remaining. The description of the show is still truncated sometimes.
Schedules Direct will be migrating our backend service from PHP to
Python starting on 2022-05-20.
What should you expect?
The Python provided API has been created to be protocol compatible, so
it's likely that you won't need to do anything if your grabber has
implemented the published API.
The new service is provided by AWS API Gateway, so the issues you may
have experienced if you were updating your schedule at your local
midnight time should now be addressed.
The methods used to generate data on our backend servers have been
updated, and there are a number of fields in the new JSON which will
cause the MD5 values to change, so your application will refresh its
local data. This is known as a cache invalidation - expect that there
will be a large amount of data downloaded.
What changes will you see?
The schedules on the backend will be refreshed more often; we have
migrated to a new data delivery mechanism from our upstream provider.
You should see 14 to 18 days of schedule data.
Images will be updated more often.
Lineup updates will be updated more often.
Schedules Direct will send lineup deletion notifications to your
registered email address 30 days before a lineup is deleted, in order
to give you time to migrate. Lineups are deleted by upstream providers
if they're consolidating headends, or ending an offering - this
typically occurs if a provider is migrating from analog (usually, the
-DEFAULT lineup) to digital-only (-X)
What should you do if you have issues after the migration?
Check to see if you're running the latest version of your application
/ grabber. Developers were provided early access to the new API, and a
number of issues were resolved.
Check the support forum for your application and engage the developer;
they'll be the ones that can help you troubleshoot the application and
the migration.
If you're still stuck, your developer will tell you to open a ticket
with Schedules Direct. Please open a lineup support ticket on the
SchedulesDirect webpage https://www.schedulesdirect.org/lineupsupport
and indicate that you're having an issue, and that the developer of
your application has directed you to open a ticket.
I have just retired my Intel NUC and done a fresh install of NPVR 5.2.7 on a MeLe Quieter3 with Win 11 Pro. A couple of issues have cropped up and I would appreciate any guidance as to how to sort them out.
I am using the NPVR Win client and when I access the Settings screen on my TV in native 3840x2160 it is all scrunched up. If I switch the display mode to 1920x1080 it displays correctly. See screenshots here : https://1drv.ms/u/s!Ai9q_te1HnG0hMpb0SV-...w?e=GPZbnA
Is this an NPVR or a PC issue?
When watching recordings or live TV with the EVR renderer specified, parts of the screen seem to lag behind and come detached then catch up (poor description I suspect but I hope you can see what I mean). If I switch to VMR9 it all seems a lot smoother but I never had issues using EVR on the NUC. Again, is this an NPVR or a PC issue?
I suspect I know the answers but would appreciate any thoughts. Thanks.
.
