Videos that doesn't stream if Real Media Catcher is recording.

[helloandwahtever]

I can reproduce your problem. I have three saved programs and all refuse to play if Media Catcher is recording. Press the "Stop Recording" button, then the streams play. So, you are not crazy. Or we both are.

Here is a new twist. This was not successful but proves interesting. I added application/x-fcs to the MIME types because that is what the server is sending. Then I followed exactly Applians video instructions for capturing imeem with Web Stream Dumper. No success. Until...

If you lower the Web Stream Dumper minimum dump size from 400k to 100k, then Web Stream Dumper begins to capture. It will record lots of 100k -> 125k .tmp files in succession. That's why I added application/x-fcs, to see if that helped Media Catcher recognize a stream. But the tmp files are unplayable.

One interesting bug in Media Catcher, is that after a tmp file is saved and the green check appears, indicating a stream is captured and saved, in the GUI two or more already saved tmp files' sizes will continue to increment upward in size. After the complete stream is viewed however, none of the dozens of tmp files are playable. The one byte hex view is gibberish. Or at least no hex views contain FLV header or metadata info.

[Gingko]

Yes, I also made some steps similar to yours, especially using the "Web Stream Dumper" options, and lowering the dump size, with exactly the same result as you : a lot of "tmp" files that are useless for reading.

A network analysis using Wireshark (formerly Ethereal) let me thinking that the "FLV" header is not even present in the stream. But I don't know the protocol, so maybe this is normal.

Otherwise, it looks like that the plug-in corresponding to this stream is "HTTP Media Streams" (because if I disable only this one, the video can play normally, but of course it still can't be captured ; also, the stream dumped by Wireshark is identified as HTTP).

Wireshark shows also that, with "normal" use or Real Media Catcher, the streaming begins anyway, but seems to be abruptly interrupted after a very short time.

I think that the site uses Wowza Media Server Pro configured with its "securetoken" template. This template verifies using an encrypted exchange that the used player is an authorized player. There is probably also some server side scripting (Wowza Media Server Pro seems to allow that) that shutdowns completely all connections to the used IP if any unknown player tries simultaneously to connect to the same stream.

The used player is JW FLV Media Player (this web address is present inside the player). You could also read this on the web site of this player.

Admins note: Thanks for the information, though we do like to refer people to our own Free FLV Player instead... :-)

[JacquesFacial]

Yo !

I have the same problem as Gingko.

Here is what I found :

The config file is a URL like
http://www.recordme.tv/playerconfig-...33137278871250

It contains the following data :

<config>
<file>
/playerplaylist-20410657-20081126135553-523.8-1315.4
</file>
<autostart>true</autostart>
<streamer>rtmpt://media-5.recordme.tv/securetoken</streamer>
<bufferlength>5</bufferlength>
<skin>/swf/recordme-skin.swf</skin>
</config>

This confirms the fact that a secure token is used.

The URL http://www.recordme.tv/playerplaylis...3-523.8-1315.4 gives the following data :

<playlist version="1">
<trackList>
<track>
<title>20410657</title>
<location>20410657-MP4NORMAL.mp4</location>
<meta rel="type">video</meta>
<meta rel="start">523.8</meta>
<meta rel="end">1315.4</meta>
<annotation>00:08:43-00:21:55 Duration 00:13:11</annotation>
</track>
</trackList>
</playlist>

So I guess the file that is used for the source is
rtmpt://media-5.recordme.tv/securetoken/20410657-MP4NORMAL.mp4

Unfortunately, I don't know witch software is able to read / rip it

If you have more information, please give me an update !