2011-03-05, 10:39 AM
NextPVR 2.03 vs. GB-PVR 1.4.7
As NextPVR 2.0.3 is out of Beta and GB-PVR 1.4.7 doesn't get any new code I tried to switch to NextPVR, even if I'm nearly happy with GB-PVR.
The following is based on experience with GB-PVR on XP and 7 (32) and on tests with NextPVR on 7.
Unfortunately, after my tests I still clearly prefer GB to Next.
This could partly change over time. Reasons for this estimation include:
- habituation to new handling
- customization of new program
- different style of new program with no possibility to customize (taste of programmer)
- maturity
- output file format
To give some details: Channel switching in Live TV mode, keys for switching between full screen and normal screen, bad looking fonts in scaled screens (i.e. windows), missing visual feedback of running Recording Service, handling and presentation of manual recordings, a lot of options that pop up only when mouse is over them.
And the output file format of recordings. At the moment this is the most important reason.
In two areas I found Next to better GB: the separation of program files and program data, and the handling of long paths (to pick up below).
As I use analog TV exclusively I'm used to .mpg files, which are program streams, I assume.
Because I watch all videos from outside of the PVR and with VLC media player I have the same problem as Nistrod with .ts files (http://forums.nextpvr.com/showthread.php...post405759). I can acknowledge that the viewer in NextPVR shows the duration of the recordings correctly. This problem even made me look for an alternative viewer for my usual video viewing and found MPC Home Cinema to be quite good. E.g. it shows the duration of the .ts files in question, is fast and shows a lot of formats. But to have preferably only one player for most viewing tasks I still find VLC better.
Assumedly I will stay with analog TV for some time to come. And GB has quite a lot of what I need. So why should I switch to Next at all?
There is one problem with GB I didn't find a solution for that would be solved with Next.
Very long paths in GB-PVR
I don't know if this problem is handled in the forum elsewhere. I don't know how I could search for it.
Sometimes I had empty recordings with GB on XP and an error message indicating that GB couldn't recover. So subsequent recordings got lost also. Then the system had to be restarted (manually) to get GB working again.
This happend with shows that had very long subtitles in the XMLTV file, probably when the overall path length of the recording file exceeded 255, with a pattern like this:
[drive:]\GBPVR\title-very_long_subtitle\title-very_long_subtitle.mpg
Somewhere I read that there was an option to strip the directory part of the recording. But I'd like to keep it.
From then I just did the recordings I know would be problematic manually and the rest in the usual way.
Is there a way to make GB handle shows with very long subtitles, e.g. by augmenting the maximum path length considerably or by silently cutting the subtitle if it would cause a too long path name?
- next
PS: I'm happy that "NextPVR" seemingly has won the name war over "g3pvr" and other affected, contrived and mannered products of the marketing and PR departements...
As NextPVR 2.0.3 is out of Beta and GB-PVR 1.4.7 doesn't get any new code I tried to switch to NextPVR, even if I'm nearly happy with GB-PVR.
The following is based on experience with GB-PVR on XP and 7 (32) and on tests with NextPVR on 7.
Unfortunately, after my tests I still clearly prefer GB to Next.
This could partly change over time. Reasons for this estimation include:
- habituation to new handling
- customization of new program
- different style of new program with no possibility to customize (taste of programmer)
- maturity
- output file format
To give some details: Channel switching in Live TV mode, keys for switching between full screen and normal screen, bad looking fonts in scaled screens (i.e. windows), missing visual feedback of running Recording Service, handling and presentation of manual recordings, a lot of options that pop up only when mouse is over them.
And the output file format of recordings. At the moment this is the most important reason.
In two areas I found Next to better GB: the separation of program files and program data, and the handling of long paths (to pick up below).
As I use analog TV exclusively I'm used to .mpg files, which are program streams, I assume.
Because I watch all videos from outside of the PVR and with VLC media player I have the same problem as Nistrod with .ts files (http://forums.nextpvr.com/showthread.php...post405759). I can acknowledge that the viewer in NextPVR shows the duration of the recordings correctly. This problem even made me look for an alternative viewer for my usual video viewing and found MPC Home Cinema to be quite good. E.g. it shows the duration of the .ts files in question, is fast and shows a lot of formats. But to have preferably only one player for most viewing tasks I still find VLC better.
Assumedly I will stay with analog TV for some time to come. And GB has quite a lot of what I need. So why should I switch to Next at all?
There is one problem with GB I didn't find a solution for that would be solved with Next.
Very long paths in GB-PVR
I don't know if this problem is handled in the forum elsewhere. I don't know how I could search for it.
Sometimes I had empty recordings with GB on XP and an error message indicating that GB couldn't recover. So subsequent recordings got lost also. Then the system had to be restarted (manually) to get GB working again.
This happend with shows that had very long subtitles in the XMLTV file, probably when the overall path length of the recording file exceeded 255, with a pattern like this:
[drive:]\GBPVR\title-very_long_subtitle\title-very_long_subtitle.mpg
Somewhere I read that there was an option to strip the directory part of the recording. But I'd like to keep it.
From then I just did the recordings I know would be problematic manually and the rest in the usual way.
Is there a way to make GB handle shows with very long subtitles, e.g. by augmenting the maximum path length considerably or by silently cutting the subtitle if it would cause a too long path name?
- next
PS: I'm happy that "NextPVR" seemingly has won the name war over "g3pvr" and other affected, contrived and mannered products of the marketing and PR departements...