The VideoLAN Forums

Hi there!

After some time of successful TV playback, I consitently experience video freeze & 100% CPU usage on vlc.exe process when watching TV from a Freebox V3.

This happens with any TV channel, and takes some time (5 - 10minutes?)to happen. Then have to kill the process (several times!) before it goes away.

I have not experienced this with VLC 0.8.4a, it only happens when moving to v0.8.5 and goes away if I revert to previous release.
Tested on 2 different machines: a laptop (Intel Centrino / ATI Mobility AGP / WinXP SP2) and desktop (AMD XP1800+ / GF6600 AGP / WinXP XP2). Note: WIFI link between the FBX and the PC(s).

I tried both VLC 0.8.5 from VideoLAN web site and also the one recompiled & pre-configured by Free (from their web site).

Cannot find references to that problem anywhere.. thanks for your help!

Hello,

I am in the same situation and for me it is exactly after 10 minutes and only with 0.8.5 version
It seems also that a common point is the use of the v3 version of the freebox.
I will also get the staff of Free aware about this problem but maybe it can be addressed by the VLC team too !

In the hope that a future version of VLC could issue this problem...

P.S. : The TV playback is streamed via the RTSP protocol.

Yup you're right, happens after 10 minutes sharp.. weird.. but repeatable!

Yep, me too.

Same story as the other two. Freebox V3. Those who have the later versions of the freebox don't seem to be having the same problem.

They haven't mentioned it, but the 0.8.5 is the version that has been used to make the HD compatible version that free (our isp) has released to let us watch HDTV streams. This being the case, we're all without HD until this point can be addressed, and we're all pulling our hair out !

We've all tried the 0.8.4 version which works perfectly for SD streams but can't play back the HD channel that has just come on line.

Any ideas?

It has to be noticed that the v 0.8.5 stop to work after 10 mins on SD chanels too, making the whole use of the "multiposte" of free impossible.
The blocking happens either with wifi or rj45 connexion.
I had the following error yesterday:
---
Packetizer_mpeg4audio debug: emulated sync word (no sync on following frame)
main warning: buffer is 52679 in advance, triggering downsampling
---
But I'm unsure the problem comes from there...

Thanks for your help!
PS: I tried with the last nigthly build 31st June 0:something v 0.8.6, and the problem is still there.

I think the same thing happens to me while streamiing video using RTSP, although I don't see 100% CPU usage -- just the video freeze. It also only happens (perfectly reproducibly) on my notebook but not on the desktop machine. There are a lot of differences between them (Pentium-M vs Xeon CPU, Matrox vs ATI video card, ...) so this probably doesn't help to isolate the problem but it at least seems to indicate that the bug happens only with some hardware.

Also, 0.8.4a works just fine on the notebook (no HD, of course).

I experienced exactlly the same problem with v 0.8.5 and Free multiposte RTSP flow: 100% CPU and freeze after around 10 min

not sure if the last warnings in the log are related to the bug:
..................
main warning: PTS is out of range (508684199), dropping buffer
main warning: PTS is out of range (508661543), dropping buffer
main warning: PTS is out of range (508639749), dropping buffer
main warning: PTS is out of range (508648610), dropping buffer

Thanks for your help

Sorry, but I speak English very badly. I thus go French ecrire.

Depuis la version 0.85 de VLC, le CPU atteint 100% après un certains temps d'utilisation du multiposte sans changer de chaîne et cela avec tous les logiciels multiposte.

Par exemple nous avons remarqué grâce à une bonne partit de la communauté qu'avec la version de VLC 0.85 le bug des 100% du CPU ce produit à environs 10 - 20 minutes de visualisation d'une chaîne (sans la changer)
La version de VLC 0.86a (la dernière) lui aussi présente ce bug mais à environs 2h d'utilisation (sans changer de chaîne).

Nous recevons plein de messages dû à ce bug très gênant sur nos forums surtout sur le forum d'adsl TV.
Voir ici > http://www.adsltv.org/punbb/viewtopic.php?id=2636

Quand cela se produit, la meilleur façon de revenir à la normal et souvent de rebooter le PC.

Pour information même sans l'activeX VLC le bug se produit.

Merci A+

Quelle est la consommation mémoire de VLC ?

En moyenne à 19.5 mo avec VLC seul sans utiliser de filtre.
Et 26 mo en utilisant le fondu comme filtre utilisé par tous les logiciels multiposte pour une meilleur qualité d'image.

Mais comme précisé tous les logiciels utilisent l'activeX de VLC, mais meme en vlc seul le prob persiste.

Toute la communautés Freennaute espère cette résolution.
Merci pour votre message

Une idée de se qu'il pourrai clocher?
Si y a besoin de faire des test je suis la
A+

Salut


J'ai pu tester le nightly builds VLC version 0.9 (26-Feb-2007 00:37) pendant 4h sans changer de chaine et tout fonctionne tres bien.

De plus la consommation mémoire a diminué par rapport aux ancienne version.
Elle était de 26 mo avec filtre (Fondu) et passe à 20 mo toujours avec Filtre.
Donc pour cette version aucun probleme.

Mais je comprend pas pourquoi j'ai une fenetre noir DOS qui s'ouvre quand je lance une instance de VLC.
Exemple >


Mais avec cette version elle empêche la connexion à la chaine en utilisant l'active X

Y a t-il un moyen d'utiliser l'active X et d'enlever cette fenetre noir ?

Merci A+

Autre test mais avec 9h d'affilé sans changer de chaine.

hello

I'm a french developper just like Christoliquide.

We were happy to see that you released vlc0.8.6-bugfix and we have tried it !
But the problem is still running.. we watched TV playback via "the freebox broadcast", and after two hours we have a 100% CPU usage on vlc.exe process...

We hope that you are able to resolve this in the 0.9 version...

Hey, I've set the option to allow vlc to show what i'm listening too.. and it doesn't show on my msn... anyone know what's up?

Blair
http://www.streetcode.org

I think the problem that VLC (when doing TV-playback by RTSP) consumes 100% of CPU after some time (3 hours in my case) is related to the version of the live555 library. I have seen that the same problem (of 100% CPU usage after 3 hours) appears on all three versions:

vlc-0.8.6a, vlc-0.8.6-bugfix and vlc-0.9.0-svn

if I compile them (under Linux) with the live555 version from 11/1/2007. However after upgrading live555 to the version of 20/2/2007 even the version vlc-0.8.6a is working fine (after recompilation). I have tested more than 9 hours without any problem.

Maybe it would be a good idea to repackage the official vlc-0.8.6a windows binary package in order to replace the live555 library by the most recent version. This appears reasonable since vlc-0.8.6a needs not to be patched itself and it would avoid complications for people who are not aware how to get the bugfix version etc.

Actually, in the above post of Christoliquide one can see that the vlc-0.9.0 nightly build version depends on live555 from 20/2/2007 (the latest version) and therefore it works without the 100%-CPU bug.

Ca fonctionne nickel avec la version de VLC 0.86b
Deviendra t-elle officielle ?
Bravo