Why is RTV sometimes acting "stupid"

Archived from groups: alt.video.ptv.replaytv (More info?)

Jerry Bank wrote:
> Does anyone have any idea of why RTV will sometimes cancel connections,
> or sometime cancel recordings, when they conflict. It should know that a
> recording is coming up and move the connection, and move the connection
> when it is recording.
>
> Just wondering.

I have never seen a recording interrupted for a connect.

Archived from groups: alt.video.ptv.replaytv (More info?)

On Thu, 09 Sep 2004 13:35:25 -0400, Tony D <Tony_D@nospam.com> wrote:

>Jerry Bank wrote:
>> Does anyone have any idea of why RTV will sometimes cancel connections,
>> or sometime cancel recordings, when they conflict. It should know that a
>> recording is coming up and move the connection, and move the connection
>> when it is recording.
>>
>> Just wondering.
>
>I have never seen a recording interrupted for a connect.

Several people seem to have reported this happening when they are
using the modem in the Replay. I've never use mine (always ethernet)
and it doesn't interfere with recording.

--
107 days until the winter solstice celebration

Mark Lloyd
http://notstupid.laughingsquid.com

Archived from groups: alt.video.ptv.replaytv (More info?)

>Does anyone have any idea of why RTV will sometimes cancel connections,
>or sometime cancel recordings,

If the connection starts before the recording and runs long you miss the
recording but it is not supposed to start a connection during the recording.

Archived from groups: alt.video.ptv.replaytv (More info?)

gfretwell@aol.com (Greg) shaped the electrons to say:
>If the connection starts before the recording and runs long you miss the
>recording but it is not supposed to start a connection during the recording.

I'm still stunned by the fact this behavior is in a shipping product.
For a DVR recording should override *everything*. If it can't do both
at the same time (like TiVo), then it should just drop the call and
try again later if it is time to record something.

It should be unacceptable for any DVR to just skip a requested
recording for any reason other than a conflict with a higher priority
recording.

-MZ, RHCE #806199299900541, ex-CISSP #3762
--
<URL:mailto:megazoneatmegazone.org> Gweep, Discordian, Author, Engineer, me.
"A little nonsense now and then, is relished by the wisest men" 508-755-4098
<URL:http://www.megazone.org/&gt; <URL:http://www.eyrie-productions.com/&gt; Eris

Archived from groups: alt.video.ptv.replaytv (More info?)

Tony D wrote:
> Jerry Bank wrote:
>
>> Does anyone have any idea of why RTV will sometimes cancel
>> connections, or sometime cancel recordings, when they conflict. It
>> should know that a recording is coming up and move the connection, and
>> move the connection when it is recording.
>>
>> Just wondering.
>
>
> I have never seen a recording interrupted for a connect.

INfo request

1: I assume by connection you mean to it's service to see what shows
are, in fact, upcoming

2: What is the "normal" time of day for said connection.

3: Can I tell it to connect say, at 10am? (nothing on, I'm just getting
home from a very long night at work and will soon make a crashing sound
as I fall upon the bed,, (like in about 2 minutes, right after you...
Well you know what you do when sitting in the smallest sitting room in
your house right)

One thing I've noticed is sometimes the shows change.. I have two
different TV listings one shows a show, one does not, for the same hour
of the same night.

Archived from groups: alt.video.ptv.replaytv (More info?)

I still bet this happens because the RTV THINKS it can call home and be done in
time but the connection runs long. The RTV does not know what the host has in
the pipe or how long it will take, particularly on a dialup.

Archived from groups: alt.video.ptv.replaytv (More info?)

In article <414092b0$1_2@127.0.0.1>, Tony_D@nospam.com says...
> Jerry Bank wrote:
> > Does anyone have any idea of why RTV will sometimes cancel connections,
> > or sometime cancel recordings, when they conflict. It should know that a
> > recording is coming up and move the connection, and move the connection
> > when it is recording.
> >
> > Just wondering.
>
> I have never seen a recording interrupted for a connect.
>
It didn't interrupt the recording. It just cancelled it. One would
think that it would allow enough time for the connect. If the connect
runs long, it can interrupt that and let the recording take place. Not
so hard to do!
--
Jerry Bank
Trenton, New Jersey
Music is the language of the gods.

Archived from groups: alt.video.ptv.replaytv (More info?)

On Fri, 10 Sep 2004 17:40:47 GMT, Jerry Bank <bankcello@peoplepc.com>
wrote:

>In article <414092b0$1_2@127.0.0.1>, Tony_D@nospam.com says...
>> Jerry Bank wrote:
>> > Does anyone have any idea of why RTV will sometimes cancel connections,
>> > or sometime cancel recordings, when they conflict. It should know that a
>> > recording is coming up and move the connection, and move the connection
>> > when it is recording.
>> >
>> > Just wondering.
>>
>> I have never seen a recording interrupted for a connect.
>>
>It didn't interrupt the recording. It just cancelled it.

That's definately an interruption.

> One would
>think that it would allow enough time for the connect. If the connect
>runs long, it can interrupt that and let the recording take place. Not
>so hard to do!

And if you have a service with a lot of channels (Dish Network {more
so with New York locals} seems to have the most), at can take a lot
longer to get the guide.

--
106 days until the winter solstice celebration

Mark Lloyd
http://notstupid.laughingsquid.com

Archived from groups: alt.video.ptv.replaytv (More info?)

>If the connect
>runs long, it can interrupt that and let the recording take place.

If you stop this thing in the middle of a connection it can end up a door stop
until it gets a good connection all the way through.
BTDT
A lot of stuff goes on, particularly if there is some software thing coming
down.
Mine just got confused about it's activation status but it took a full connect
(243z-7) to fix it.