SageTV Community  

Go Back   SageTV Community > SageTV Products > SageTV Software

Notices

SageTV Software Discussion related to the SageTV application produced by SageTV. Questions, issues, problems, suggestions, etc. relating to the SageTV software application should be posted here. (Check the descriptions of the other forums; all hardware related questions go in the Hardware Support forum, etc. And, post in the customizations forum instead if any customizations are active.)

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 03-12-2018, 11:25 PM
bigbill's Avatar
bigbill bigbill is offline
Sage Aficionado
 
Join Date: Dec 2006
Location: San Diego, California
Posts: 372
Odd recording/Playback issues over the last two weeks.

I am recording OTA shows via a couple HDHR on a Sage 9.1.8 version of the software. Over the last couple of weeks some of the recordings are getting corrupted, or something I can't explain. My recordings usually show the green bar on the side to indicate the recording, It may show comskip segments or not. On a few shows i am seeing a very similar issue where the green bar only goes half way, then the second half of the show is red. When you try to watch one of them it just ends out immediately. The only way to get to watch a show that looks like that is to start the show with the Play button and simultaneously press a skip back button. Then you can skip all the way back to the beginning and the whole show is there. You get the hold one hour show in what appears to be a half hour. It seems to be random shows that air on different channels.
I did notice this similar condition in the recording detail from all the affected shows since I discovered the detail discrepancy on Friday.
A one hour show that airs 10:00 PM - 11:00 PM shows in the "Recorded from 8:59 PM to 10:00 PM Do i have something corrupt? See a screen shot attached. I highlighted what may be a clue in Yellow

PS. It been happening for a couple weeks now, so its not related to Daylight Savings time. I did check, and the time on the sage server is correctly being updated by an NTP server. I did turn off the sagetv server update option in the detailed setup a while back thinking there wasn't any more sage server to update the time anymore.

Oh, I rebooted the SageTV server Sunday morning around 9am as I thought there might be an issue there as it hadn't been rebooted in months. -Bill
Attached Images
File Type: jpg showdiscrepancy.JPG (56.2 KB, 67 views)
__________________
Sage Server: SageTV v9.1.8
Hardware Dell T20 Mini Tower, 4th Gen Pentium, 8GB RAM, Win10 Pro 64 bit, 3 x 4TB WD Green, 128GB SSD boot drive. Capture: 2 Dual HDHR, (OTA Winegard HD8200U, CM4221HD), 3 @ STP-HD200's fw=v20100909 TV's: 70", 55" & 40" Sony's - Playon/PlayLater, Blue Iris. FFMPEG script converting MPEG2 to MP4 long term storage.

Motorhome Sage Server: SageTV v9.1.8 Intel NUC6CAYH, HD300, Nvidia Shield 2017, 1 Dual HDHR 4TB Passport storage, Winegard BatWing RV antenna.

Last edited by bigbill; 03-12-2018 at 11:30 PM.
Reply With Quote
  #2  
Old 03-13-2018, 10:27 AM
bigbill's Avatar
bigbill bigbill is offline
Sage Aficionado
 
Join Date: Dec 2006
Location: San Diego, California
Posts: 372
More Screen Shots..

Here are more screen shots of what I am seeing.
Attached Images
File Type: jpg showdiscrepancyGreenRedBarView.JPG (30.3 KB, 64 views)
File Type: jpg showdiscrepancy2ndShow.JPG (118.3 KB, 52 views)
__________________
Sage Server: SageTV v9.1.8
Hardware Dell T20 Mini Tower, 4th Gen Pentium, 8GB RAM, Win10 Pro 64 bit, 3 x 4TB WD Green, 128GB SSD boot drive. Capture: 2 Dual HDHR, (OTA Winegard HD8200U, CM4221HD), 3 @ STP-HD200's fw=v20100909 TV's: 70", 55" & 40" Sony's - Playon/PlayLater, Blue Iris. FFMPEG script converting MPEG2 to MP4 long term storage.

Motorhome Sage Server: SageTV v9.1.8 Intel NUC6CAYH, HD300, Nvidia Shield 2017, 1 Dual HDHR 4TB Passport storage, Winegard BatWing RV antenna.
Reply With Quote
  #3  
Old 03-13-2018, 01:01 PM
trk2 trk2 is offline
Sage Aficionado
 
Join Date: Jan 2006
Location: Maine
Posts: 341
It is possible you are seeing the issue Jeff addressed here. I don't believe these changes have been rolled into the latest Windows installer yet, if that is what you are using.
Reply With Quote
  #4  
Old 03-13-2018, 03:24 PM
bigbill's Avatar
bigbill bigbill is offline
Sage Aficionado
 
Join Date: Dec 2006
Location: San Diego, California
Posts: 372
It's close, but I don't have the erratic skip forward or back like Jeff has, once I am able to get back to the beginning of the file I am able to watch the show and skip the commercials. I posted to that thread and referenced this one.

Thanks for pointing out that thread!! -Bill
__________________
Sage Server: SageTV v9.1.8
Hardware Dell T20 Mini Tower, 4th Gen Pentium, 8GB RAM, Win10 Pro 64 bit, 3 x 4TB WD Green, 128GB SSD boot drive. Capture: 2 Dual HDHR, (OTA Winegard HD8200U, CM4221HD), 3 @ STP-HD200's fw=v20100909 TV's: 70", 55" & 40" Sony's - Playon/PlayLater, Blue Iris. FFMPEG script converting MPEG2 to MP4 long term storage.

Motorhome Sage Server: SageTV v9.1.8 Intel NUC6CAYH, HD300, Nvidia Shield 2017, 1 Dual HDHR 4TB Passport storage, Winegard BatWing RV antenna.
Reply With Quote
  #5  
Old 03-14-2018, 10:12 AM
bigbill's Avatar
bigbill bigbill is offline
Sage Aficionado
 
Join Date: Dec 2006
Location: San Diego, California
Posts: 372
Another new Screen shot.

I was thinking I may have to do with the clock change, but this recording of the news was after the change happened. It seems to think it started recording at 10:30 but the actual recording is from 11:00 to 11:30

I just added a second SS that does NOT have the extra line "Recorded from" Is that a clue?


-Bill
Attached Images
File Type: jpg CBSnewsOddError.JPG (143.9 KB, 34 views)
File Type: jpg CBSnewsNoError.JPG (147.5 KB, 34 views)
__________________
Sage Server: SageTV v9.1.8
Hardware Dell T20 Mini Tower, 4th Gen Pentium, 8GB RAM, Win10 Pro 64 bit, 3 x 4TB WD Green, 128GB SSD boot drive. Capture: 2 Dual HDHR, (OTA Winegard HD8200U, CM4221HD), 3 @ STP-HD200's fw=v20100909 TV's: 70", 55" & 40" Sony's - Playon/PlayLater, Blue Iris. FFMPEG script converting MPEG2 to MP4 long term storage.

Motorhome Sage Server: SageTV v9.1.8 Intel NUC6CAYH, HD300, Nvidia Shield 2017, 1 Dual HDHR 4TB Passport storage, Winegard BatWing RV antenna.

Last edited by bigbill; 03-14-2018 at 10:43 AM.
Reply With Quote
  #6  
Old 03-14-2018, 11:28 AM
Narflex's Avatar
Narflex Narflex is offline
Sage
 
Join Date: Feb 2003
Location: Redondo Beach, CA
Posts: 6,301
If you can post the sagetv server logs from when one of these recordings is made...that'd be super helpful.
__________________
Jeffrey Kardatzke
Google
Founder of SageTV
Reply With Quote
  #7  
Old 03-14-2018, 11:42 AM
UgaData's Avatar
UgaData UgaData is offline
Sage Aficionado
 
Join Date: Sep 2005
Posts: 345
The shows in error don't indicate which tuner they were recorded on.

The show without the error does indicate the tuner that encoded it.

Although you rebooted the Sage server, did you reboot the tuners?

Do the tuners have the latest firmware?
__________________
"Unencumbered by the thought process"

The only constant in the Universe is change.
Reply With Quote
  #8  
Old 04-07-2018, 10:05 AM
bigbill's Avatar
bigbill bigbill is offline
Sage Aficionado
 
Join Date: Dec 2006
Location: San Diego, California
Posts: 372
Had 4 shows record back to back last night. No red areas in them. But one of the shows has the same create and modified dates, the rest look like they should be, one hour apart. The zip file is really a .7z file, so you will probably need to rename to open those logs. I'm a novice at reading them so maybe someone else will see something. The screen shot shows the recorded files and you can see which has the incorrect timestamp and which do not.

-Bill

PS. If there is a key to help understand them so I know what the different things defined in the log like Carny etc, that would be much appreciated.
Attached Images
File Type: jpg 11pmShows.JPG (51.5 KB, 18 views)
Attached Files
File Type: zip bigbill.zip (381.7 KB, 19 views)
__________________
Sage Server: SageTV v9.1.8
Hardware Dell T20 Mini Tower, 4th Gen Pentium, 8GB RAM, Win10 Pro 64 bit, 3 x 4TB WD Green, 128GB SSD boot drive. Capture: 2 Dual HDHR, (OTA Winegard HD8200U, CM4221HD), 3 @ STP-HD200's fw=v20100909 TV's: 70", 55" & 40" Sony's - Playon/PlayLater, Blue Iris. FFMPEG script converting MPEG2 to MP4 long term storage.

Motorhome Sage Server: SageTV v9.1.8 Intel NUC6CAYH, HD300, Nvidia Shield 2017, 1 Dual HDHR 4TB Passport storage, Winegard BatWing RV antenna.
Reply With Quote
  #9  
Old 04-07-2018, 10:55 AM
bigbill's Avatar
bigbill bigbill is offline
Sage Aficionado
 
Join Date: Dec 2006
Location: San Diego, California
Posts: 372
Ok. I got the show Hawaii50 to become 1/2 red by moving it from one local drive E: to another F: around 9:24am today. It was the only show from last night that had the modified timestamp the same as the created timestamp.

I see it gets library imported again at 9:38 am. There is what appears to be a RECOVERY keyword a few entries further down.

I have attached the log from the time I moved the file.

Its a 7z file renamed to .zip

Should I be stopping the sage service when I move the file to another drive? I am pretty sure I read that I should have Sage still running when i move a show. -Bill
Attached Files
File Type: zip sagetv_0.zip (209.7 KB, 16 views)
__________________
Sage Server: SageTV v9.1.8
Hardware Dell T20 Mini Tower, 4th Gen Pentium, 8GB RAM, Win10 Pro 64 bit, 3 x 4TB WD Green, 128GB SSD boot drive. Capture: 2 Dual HDHR, (OTA Winegard HD8200U, CM4221HD), 3 @ STP-HD200's fw=v20100909 TV's: 70", 55" & 40" Sony's - Playon/PlayLater, Blue Iris. FFMPEG script converting MPEG2 to MP4 long term storage.

Motorhome Sage Server: SageTV v9.1.8 Intel NUC6CAYH, HD300, Nvidia Shield 2017, 1 Dual HDHR 4TB Passport storage, Winegard BatWing RV antenna.
Reply With Quote
  #10  
Old 04-07-2018, 06:13 PM
wnjj wnjj is offline
Sage Icon
 
Join Date: Jan 2009
Posts: 1,070
So I'll have to retract one of my earlier statements. I do have several shows that have the same created and modified time (at the start). That was likely the same problem I had with those funny summer Olympic shows I copied 2 years ago.

Here's the thing: The ONLY shows that are messed up are ones that have recordings following them on the same tuner but not all of that type are messed up.

If you look in your log files, you will see "switchOutputFile0" whenever the capture graph is asked to change the file without stopping/starting. From what I've read online here you're supposed to stop the capture graph, change the filename, then restart. I'm pretty sure the current Sage code does not do this but just switches the file name. I'm guessing that results in files left hanging that never get their modified date corrected. I'm not sure why some of the work but unsupported methods are likely to be flakey.
Reply With Quote
  #11  
Old 04-07-2018, 07:55 PM
wnjj wnjj is offline
Sage Icon
 
Join Date: Jan 2009
Posts: 1,070
Try setting “seeker/fast_mux_switch=false” in sage.properties (with sage shut down when you edit). I think that forces a complete graph rebuild between shows.
Reply With Quote
  #12  
Old 04-07-2018, 10:15 PM
bigbill's Avatar
bigbill bigbill is offline
Sage Aficionado
 
Join Date: Dec 2006
Location: San Diego, California
Posts: 372
I just edited it and started the service. Looks like I have 4 back to back shows recording tomorrow evening on the same channel.

Thanks! Bill
__________________
Sage Server: SageTV v9.1.8
Hardware Dell T20 Mini Tower, 4th Gen Pentium, 8GB RAM, Win10 Pro 64 bit, 3 x 4TB WD Green, 128GB SSD boot drive. Capture: 2 Dual HDHR, (OTA Winegard HD8200U, CM4221HD), 3 @ STP-HD200's fw=v20100909 TV's: 70", 55" & 40" Sony's - Playon/PlayLater, Blue Iris. FFMPEG script converting MPEG2 to MP4 long term storage.

Motorhome Sage Server: SageTV v9.1.8 Intel NUC6CAYH, HD300, Nvidia Shield 2017, 1 Dual HDHR 4TB Passport storage, Winegard BatWing RV antenna.
Reply With Quote
  #13  
Old 04-07-2018, 11:06 PM
bigbill's Avatar
bigbill bigbill is offline
Sage Aficionado
 
Join Date: Dec 2006
Location: San Diego, California
Posts: 372
I also just corrected the modified timestamp for the show that got screwed up when I moved it this morning. After fixing the mod time I moved it to another drive... It did not remove the red line for the show or fix anything. Bummer.
The log looks very different than this mornings log where it deleted the file first. Then imported it in.

If I get another incorrect time on a file I will try to change the modified date prior to moving it the first time.

-Bill
__________________
Sage Server: SageTV v9.1.8
Hardware Dell T20 Mini Tower, 4th Gen Pentium, 8GB RAM, Win10 Pro 64 bit, 3 x 4TB WD Green, 128GB SSD boot drive. Capture: 2 Dual HDHR, (OTA Winegard HD8200U, CM4221HD), 3 @ STP-HD200's fw=v20100909 TV's: 70", 55" & 40" Sony's - Playon/PlayLater, Blue Iris. FFMPEG script converting MPEG2 to MP4 long term storage.

Motorhome Sage Server: SageTV v9.1.8 Intel NUC6CAYH, HD300, Nvidia Shield 2017, 1 Dual HDHR 4TB Passport storage, Winegard BatWing RV antenna.

Last edited by bigbill; 04-08-2018 at 09:58 AM.
Reply With Quote
  #14  
Old 04-29-2018, 11:46 AM
bigbill's Avatar
bigbill bigbill is offline
Sage Aficionado
 
Join Date: Dec 2006
Location: San Diego, California
Posts: 372
Quote:
Originally Posted by wnjj View Post
Try setting “seeker/fast_mux_switch=false” in sage.properties (with sage shut down when you edit). I think that forces a complete graph rebuild between shows.
Still working perfectly 3 weeks after making the properties change! No more 1/2 red/green bars since. All the modified timestamps have been correct since then.

-Bill
__________________
Sage Server: SageTV v9.1.8
Hardware Dell T20 Mini Tower, 4th Gen Pentium, 8GB RAM, Win10 Pro 64 bit, 3 x 4TB WD Green, 128GB SSD boot drive. Capture: 2 Dual HDHR, (OTA Winegard HD8200U, CM4221HD), 3 @ STP-HD200's fw=v20100909 TV's: 70", 55" & 40" Sony's - Playon/PlayLater, Blue Iris. FFMPEG script converting MPEG2 to MP4 long term storage.

Motorhome Sage Server: SageTV v9.1.8 Intel NUC6CAYH, HD300, Nvidia Shield 2017, 1 Dual HDHR 4TB Passport storage, Winegard BatWing RV antenna.
Reply With Quote
  #15  
Old 04-30-2018, 11:31 AM
wnjj wnjj is offline
Sage Icon
 
Join Date: Jan 2009
Posts: 1,070
Quote:
Originally Posted by bigbill View Post
Still working perfectly 3 weeks after making the properties change! No more 1/2 red/green bars since. All the modified timestamps have been correct since then.

-Bill
Yeah, the code change Narflex made has been running in my system for 2 weeks and I have no bad file timestamps either, with fast switch still on.

Again, the only downside for you with that setting off is a slight loss of data between shows which is usually only noticed when viewing live. You will also miss a little if you have 'remove back to back padding on favorites' enabled where it keeps the same tuner but has to reset in between instead of hot-switching the file.
Reply With Quote
  #16  
Old 04-09-2018, 11:00 AM
Narflex's Avatar
Narflex Narflex is offline
Sage
 
Join Date: Feb 2003
Location: Redondo Beach, CA
Posts: 6,301
Quote:
Originally Posted by wnjj View Post
If you look in your log files, you will see "switchOutputFile0" whenever the capture graph is asked to change the file without stopping/starting. From what I've read online here you're supposed to stop the capture graph, change the filename, then restart. I'm pretty sure the current Sage code does not do this but just switches the file name. I'm guessing that results in files left hanging that never get their modified date corrected. I'm not sure why some of the work but unsupported methods are likely to be flakey.
We wrote out our file sink filter...so we won't be subjected to the bug you are referring to here. I'm quite sure we are properly closing the files...or otherwise we would have had bug reports over the years relating to not being able to delete files that just finished recording when another one is on right after it (and we do that behavior a lot because of intelligent recording).

HOWEVER...I just looked at the code for our writer filter (called Dump): https://github.com/google/sagetv/blo.../MPEG2Dump.cpp

And we do close the file differently depending upon whether we did a fast switch or not. It does still look like we close it though. But maybe somebody else will see a problem in there that I don't.

I am very intrigued to know the answer once somebody figures out what's happening here...this is definitely a mystery.
__________________
Jeffrey Kardatzke
Google
Founder of SageTV
Reply With Quote
  #17  
Old 04-09-2018, 12:32 PM
bigbill's Avatar
bigbill bigbill is offline
Sage Aficionado
 
Join Date: Dec 2006
Location: San Diego, California
Posts: 372
I had 4 back to back shows on the same channel record last night. All of them have the correct modified date. Is it because I made this change? “seeker/fast_mux_switch=false” It had be true prior to last nights recordings.

Maybe that will help find out whats happening. My guess is most folks do not move their recordings like i do so they haven't reported this bug yet. It appears that if I do not move the recording the modified date doesn't mess up the timeline. But that is really just a guess as I don't have enough data.

-Bill
__________________
Sage Server: SageTV v9.1.8
Hardware Dell T20 Mini Tower, 4th Gen Pentium, 8GB RAM, Win10 Pro 64 bit, 3 x 4TB WD Green, 128GB SSD boot drive. Capture: 2 Dual HDHR, (OTA Winegard HD8200U, CM4221HD), 3 @ STP-HD200's fw=v20100909 TV's: 70", 55" & 40" Sony's - Playon/PlayLater, Blue Iris. FFMPEG script converting MPEG2 to MP4 long term storage.

Motorhome Sage Server: SageTV v9.1.8 Intel NUC6CAYH, HD300, Nvidia Shield 2017, 1 Dual HDHR 4TB Passport storage, Winegard BatWing RV antenna.
Reply With Quote
  #18  
Old 04-09-2018, 12:41 PM
wnjj wnjj is offline
Sage Icon
 
Join Date: Jan 2009
Posts: 1,070
Quote:
Originally Posted by bigbill View Post
I had 4 back to back shows on the same channel record last night. All of them have the correct modified date. Is it because I made this change? “seeker/fast_mux_switch=false” It had be true prior to last nights recordings.

Maybe that will help find out whats happening. My guess is most folks do not move their recordings like i do so they haven't reported this bug yet. It appears that if I do not move the recording the modified date doesn't mess up the timeline. But that is really just a guess as I don't have enough data.

-Bill
Yes, I believe fast switching is causing the bad modified times, at least on some files. I agree that it's likely always been there (as seen on my system too) but most people don't move the shows around.
Reply With Quote
  #19  
Old 04-09-2018, 04:32 PM
wnjj wnjj is offline
Sage Icon
 
Join Date: Jan 2009
Posts: 1,070
Quote:
Originally Posted by Narflex View Post
We wrote out our file sink filter...so we won't be subjected to the bug you are referring to here. I'm quite sure we are properly closing the files...or otherwise we would have had bug reports over the years relating to not being able to delete files that just finished recording when another one is on right after it (and we do that behavior a lot because of intelligent recording).

HOWEVER...I just looked at the code for our writer filter (called Dump): https://github.com/google/sagetv/blo.../MPEG2Dump.cpp

And we do close the file differently depending upon whether we did a fast switch or not. It does still look like we close it though. But maybe somebody else will see a problem in there that I don't.

I am very intrigued to know the answer once somebody figures out what's happening here...this is definitely a mystery.
Thanks for the clarification. I had forgotten about the writer filter. By closing "differently" I assume you referring to Async vs not? Does non-fast switch close the file when the graph teardown ultimately calls the CMPEG2Dump destructor, which in turn calls CloseFile with FALSE (i.e. not async)?

It looks like file writing is normally done through an AsyncIO worker thread, presumably to keep the main filter receiver loop ready for real-time data (ReceiveCanBlock=false). When fast switch happens, it queues the remaining data and a close request then proceeds to queue the new file stream. Since the new file works fine, I'm at a loss as to why the previous file didn't get the modified date set since the thread is still working normally. Everything I've read says the modified time stamp happens when you call CloseHandle and as you said, files don't seem to be locked indicating they are closed.

As for why many, but not most back-to-back files have this issue I'm wondering if the difference is whether they fall into the 5 second timeout revert to non-seamless switch or something else is causing an issue in how the async thread runs. Either one could be randomly affected by what the system or disk is doing and how 'CloseFile' is used.

It's possible that something at the OS or HDD driver level (caching?) has changed with regard to file close/time stamps causing this to show up in recent years, again only noticeable if you move back-to-back files around with fast switch on.

I can't see anything obvious yet but will keep looking. Using that dll with dump logging enabled from months ago may reveal something.
Reply With Quote
  #20  
Old 04-09-2018, 06:08 PM
Narflex's Avatar
Narflex Narflex is offline
Sage
 
Join Date: Feb 2003
Location: Redondo Beach, CA
Posts: 6,301
Quote:
Originally Posted by wnjj View Post
Thanks for the clarification. I had forgotten about the writer filter. By closing "differently" I assume you referring to Async vs not?
Yes
Quote:
Originally Posted by wnjj View Post
Does non-fast switch close the file when the graph teardown ultimately calls the CMPEG2Dump destructor, which in turn calls CloseFile with FALSE (i.e. not async)?
Yeah...I'm pretty sure that's how that works.

Quote:
Originally Posted by wnjj View Post
It looks like file writing is normally done through an AsyncIO worker thread, presumably to keep the main filter receiver loop ready for real-time data (ReceiveCanBlock=false). When fast switch happens, it queues the remaining data and a close request then proceeds to queue the new file stream. Since the new file works fine, I'm at a loss as to why the previous file didn't get the modified date set since the thread is still working normally. Everything I've read says the modified time stamp happens when you call CloseHandle and as you said, files don't seem to be locked indicating they are closed.
Yeah, I didn't see anything wrong...but the correlation of the 2 different code paths and the results people are posting are interesting. If somebody had an example of a bad timestamp that was NOT from a back-to-back recording then we're probably looking in the wrong place.

Quote:
Originally Posted by wnjj View Post
As for why many, but not most back-to-back files have this issue I'm wondering if the difference is whether they fall into the 5 second timeout revert to non-seamless switch or something else is causing an issue in how the async thread runs.
I also noticed a 'double free' if that timeout occurs, which could also possibly crash recording...so I'm guessing that timeout doesn't happen too often (and it really should never happen).

Quote:
Originally Posted by wnjj View Post
Either one could be randomly affected by what the system or disk is doing and how 'CloseFile' is used.

It's possible that something at the OS or HDD driver level (caching?) has changed with regard to file close/time stamps causing this to show up in recent years, again only noticeable if you move back-to-back files around with fast switch on.

I can't see anything obvious yet but will keep looking. Using that dll with dump logging enabled from months ago may reveal something.
Good luck! It's also interesting that this problem never came up in the prior 14 years of people using SageTV....which makes me very suspicious it's a Windows update that's causing this problem. Would be good to check on OS correlation to this problem if that wasn't done already.
__________________
Jeffrey Kardatzke
Google
Founder of SageTV
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Recording Playback Issues Post Upgrade SteveW SageTV Github Development 14 01-19-2017 12:19 PM
Extender issues after start TV recording playback starfire SageTV Github Development 30 11-08-2016 11:00 AM
HD200 - cool, but 2 issues - memory & playback issues with hdpvr agover SageTV Media Extender 3 12-16-2008 12:50 PM
Vista 64 Recording playback issues HELP!!! chrisc983 SageTV Software 1 05-08-2008 12:59 AM
Why only 2 weeks snoopy SageTV EPG Service 2 10-12-2006 08:38 PM


All times are GMT -6. The time now is 08:12 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Copyright 2003-2005 SageTV, LLC. All rights reserved.