Reply to thread

Message: <blockquote data-quote="sjevtic" data-source="post: 864547" data-attributes="member: 118214">Steve, Yes, it's a bit overwhelming, and the broad scope of the thread--anything even tangentially related to a Colossus/HD-PVR is fair game--sure isn't helping matters. The Colossus (and HD-PVR) for that matter aren't really tuner devices, so they break the TV-Server paradigm a little bit (e.g., you can't scan for channels), but as you've alluded to, there are convenient ways to deal with this, such as by using the Schedules Direct plugin. Most of what I have found here is still pretty accurate. Colossus support isn't new at this point and has been built into MediaPortal for a while now; I started at 1.2.2 and it already worked nicely there. Make sure you grab the latest drivers from the Hauppauge web site though, as the previous version had some issues.   What HDMI passthrough? There's no such thing on the Colossus, and I'm not sure what the point would be when using such a device with MediaPortal anyway. MP supports capture using the HDMI input on the Colossus, subject to some caveats. First, it won't decrypt HDCP. So, if you want to be able to watch HDCP-protected content (which your STB probably provides, at least for some channels at this point), you'll need a HDCP stripper. Second, at least in my experience, the combination of the HDMI on the Colossus and MP don't seem to be very good at working with resolution changes, which are common when tuning your STB from a SD channel to an HD one and vice versa. A lot of STBs give you the option of maintaining the same output resolution regardless of the selected content's resolution, but that isn't really desirable, as it is wasteful to record SD content scaled up to 1920 x 1080, for example. Also, I found that my STB's HDMI output went out to lunch from time to time and requiring me to power cycle the box. In short, I haven't found HDMI capture to be worthwhile. I get very good quality with component video and TOSlink audio, the resolution switching works great, and the quirks are minimal. See the last few pages in this thread for details about my experiences with the Colossus, including how to quickly change the video and audio sources associated with channels TV-Server.   Installing the Schedules Direct plugin is easy. Getting it to work is usually pretty straightforward, too. That said, you can't do anything useful with it until you have an account, so you'll need to sign up to get started. As I recall, there is a free trial period though, and even if that isn't enough for your testing, you can get something like 3 months for $6, so it's not exactly a huge expense/risk.   I'll admit to being interested in 4TR, but I haven't bitten the bullet and tried it yet. The biggest deterrent has been lack of support for MPExtended, which is important to me. Also, I don't think that Argus supports the Colossus. That wouldn't necessarily stop you from using the 4TR scheduler though, as it can use MP's TV-Server as a back end to do the tuning and recording, leaving Argus out of the picture.   I'm not clear as to what you are asking here, but I will mention a couple of things that are probably relevant:<ul> <li data-xf-list-type="ul">TV-Server generally requires decent performance for its timeshifting and recording volumes. That said, the Colossus streams are fully compressed coming off the card, so the throughput requirements per stream aren't unreasonable. I can have my 3 Colossus cards recording or timeshifting simultaneously to a run of the mill 7200 RPM 3 TB SATA-3 HDD without any issues.</li> <li data-xf-list-type="ul">When you have multiple streams running simultaneously or a fragmented volume, the access pattern will be less sequential, making it harder for the disk to keep up. Using a disk that is largely empty for recording/timeshifting will make life simpler, as fuller filesystems present more of a challenge to defragment. I move my recordings to a different volume for long term storage, thus leaving the drive mostly empty. Since there isn't anything interesting on the drive, this also has the nice side effect of preventing read requests at inopportune moments. A quality, situationally appropriate RAID implementation increases tolerance of load and fragmentation by increasing raw performance and introducing clever caching schemes, but shouldn't be necessary unless you're up to something really over the top.</li> <li data-xf-list-type="ul">Plan on using a local volume for timeshifting/recording. I tried using network volumes for a bit, and while it more or less worked, the results weren't quite as good; I ran into skipped frames and such.</li> </ul>MP doesn't really have any affinity for a particular NAS. As long as whatever storage platform you are using can be accessed as a drive letter/UNC path and performs reasonably, you shouldn't have any problems. That said, there are plenty of otherwise passable solutions out there that are rendered NAS-ty (bad pun intended) by substandard embedded software. Moreover, you should expect some blips in your media operations if your network performance isn't rock solid (i.e., that is, it is heavily loaded or contains wireless links). Also, when using Windows network shares, make sure authentication between all involved involved components "just works", either as a consequence of synchronized usernames/passwords, or better yet, by using a single domain user account. This also means that services (TV-Server, MPExtended, etc.) shouldn't be running under the system account. All of this considered, I think a NAS running Windows Storage Server would probably provide the nicest/most convenient experience, especially if you have a Windows domain, which it would obviously be able to join. Sasha</blockquote>

Verification