Created an attachment (id=1980) [details]
First video test case affected by the bug

Created an attachment (id=1981) [details]
Second video test case affected by the bug

Both this attachment and the one in Comment #1 are affected by the bug when
played in streaming. If they are copied to N900 (e.g. via Bluetooth) and played
locally, instead, both audio and video are OK.

This happens to me. Just upgraded to 5.0(2.2009.51-1)

My media server is a ubuntu 9.10 machine with mediatomb which used to work fine
in the PR1.0 firmware.

For me, this problem appeared only after update to 2.2009.51-1.002

Video files were verified as playing correctly with previous version of N900
software as well as a separate Windows XP based upnp client.

Now they get stuck on the first frame when played on the N900 via wifi, but
play correctly if copied to the N900 itself.

After more testing, many of the previously functional videos seem to be
identified as 1 second in duration (if that is what is indicated by the number
on right of timeline which reads 00:01), a small number of others are
identified with correct length but still fail to play video.  Also, when a
single frame is shown, the accompanying audio stops after anywhere from 5-30
seconds and does not continue for the duration of the file in my case.

(In reply to comment #3)
> This happens to me. Just upgraded to 5.0(2.2009.51-1)
> 
> My media server is a ubuntu 9.10 machine with mediatomb which used to work fine
> in the PR1.0 firmware.
> 

Exactly the same with me

I believe that this may be the same problem as local videos also not playing as
discussed in this thread.

http://talk.maemo.org/showthread.php?t=40675&highlight=pr1.1

Videos play in KM Player,but not in the in built media player

Streaming begins, but stops intermediately and the connection to the server
breaks and the login page comes to screen. In previous version this worked
well.

I get the same using western digital network drive and twonky. Audio playing,
still stuck on first frame for video. This is on all types of video.

This also happens for me using both Orb and XBMC as upnp servers. Audio plays
for 15-20 seconds without video, then displays a buffering message for an
instant, then stops. Audio streaming works perfectly.

I have no problem playing videos stored on the device.

(In reply to comment #7)
> I believe that this may be the same problem as local videos also not playing as
> discussed in this thread.
> 
> http://talk.maemo.org/showthread.php?t=40675&highlight=pr1.1
> 
> Videos play in KM Player,but not in the in built media player
> 

Local video started playing well after re-installation of Extra Decoder Support
and passing a couple of hours. See

http://talk.maemo.org/showthread.php?p=476597#post476597

Note that this problem only happens with xvid/mpeg4-part-2/h.263 files. h.264
files play correct, assuming that bug 8172 is avoided.

Also image browsing appear to be broken. With Twonkymedia server on Vista 64
I've the same problem reported here with videos, fully working audio streaming
and any image available from n900 (except the local images). Other upnp clients
are working ok

This happens also to me. 

My media server is a debian machine running ushare.
Streaming xvid was fine in the previous firmware.

This bug is the same as 8043 which is already fixed?

Agreed I have the exact same problems described streaming any video codec.

Incidentally my friend has an n900 and streaming with my TVersity 1.7.2.1
server on Win 7 x64 it worked fine (before the recent Maemo pushed update).

However, I since have bought the n900 and cannot stream it to my device. (this
is after the Maemo update).

Picture freezes on frame one, audio plays, scroll bar moves correctly and
jogging through the video does not update the video.

Thanks

Bug 8043 deals with HTTP streaming, rather than this bug which is regarding
UPnP streaming and is not yet fixed.

upnp is http based and when you ultimately decided to play a file, it looks the
same, underneath, as what was shown in bug 8043 - so I strongly suspect this is
fixed (internally) as well - someone on the inside will need to verify to
close.

Happening with TVersity for me;

Initialise stream through either File Manager or Media Player and I get sound
for a while but no running video.

BUT - if I copy the same file through TVersity to Local storage on the N900,
they play back fine

Happens with Elgato Eyeconnect 1.53 too. 
Worked fine before PR1.1.
Definitely needs a fix.

Comment 21 Andre Klapper 2010-01-22 14:34:46 UTC

I'm wondering if this is related to /same root issue as bug 8254 comment 20.

Thanks for the 2 files, I will try to debug why they don't play well over http.

Ok I can reproduce with the avi file (first test case) but not the mp4.

With the avi both these pipelines fail with just first frame shown but rest of
sound plays:

gst-launch -v playbin2 uri=http://<my_webserver>/test1.avi
gst-launch -v http://<my_webserver>/test1.avi ! avidemux ! dspvdec !
xvimagesink

What is interesting is that if I do:

gst-launch -v http://<my_webserver>/test1.avi ! avidemux ! dspvdec ! gdppay !
filesink location=<location>

and play that back with: gst-launch -v filesrc location=<location> ! gdpdepay !
xvimagesink on either n900 or my desktop, i get that single frame.

(In reply to comment #24)
> What is interesting is that if I do:
> 
> gst-launch -v http://<my_webserver>/test1.avi ! avidemux ! dspvdec ! gdppay !
> filesink location=<location>
> 
> and play that back with: gst-launch -v filesrc location=<location> ! gdpdepay !
> xvimagesink on either n900 or my desktop, i get that single frame.
> 

I know realize that the bug I have been commenting on 8254 rather belongs here.
I confirm the following:

1) MPEG encoded video files play fine locally and over uPnP (using DLink
NDS-323
NAS box as a server).

2) AVI contained files with MPEG compressed video play fine locally or over
uPnP

3) AVI contained files with xvid/divx encoding play fine locally, but over uPnP
play only audio (which is mpeg layer 3) and show the first frame only.

I apologize for making several posting not realizing the importance of what
plays locally vs. what is streamed.

I also have this issue. I have tested on twonky and mythtv upnp server. This
did not happen before PR1.1

This is exactly the same as #8043

*** This bug has been marked as a duplicate of bug 8043 ***

(In reply to comment #27)
> This is exactly the same as #8043
> 
> *** This bug has been marked as a duplicate of bug 8043 ***
> 

This may or may not be a duplicate of bug #8043. But the fact of the matter is,
there is STILL a problem with the video streaming and it was working prior to
the PR1.1 upgrade.

There is clearly a problem, so I do not understand why both bug #8043 is marked
as resolved.

bug 8043 is marked as resolved because it is fixed in an internal nokia build
so it will be fixed in PR1.2

UPnP streaming is exactly the same as HTTP streaming, just with added
convenience such as discovery etc.

(In reply to comment #29)
> bug 8043 is marked as resolved because it is fixed in an internal nokia build
> so it will be fixed in PR1.2
> 
> UPnP streaming is exactly the same as HTTP streaming, just with added
> convenience such as discovery etc.
> 

When will we be seeing the release of PR1.2? I'm REALLY keen on getting HTTP
streaming back.

Comment 31 Andre Klapper 2010-01-25 14:50:53 UTC

(In reply to comment #28)
> so I do not understand why both bug #8043 is marked as resolved.

See https://bugs.maemo.org/page.cgi?id=fields.html#resolution

(In reply to comment #30)
> When will we be seeing the release of PR1.2?

Nokia does not announce release dates of public updates in advance. For
followup questions to this please use a forum like talk.maemo.org as these
generic topics have nothing to do with this specific bug report. Thanks!

This bug is not fixed as of update 3.2010.02-8

After update to 3.2010.02-8 when I tried to free up memory as much I could I
succeeded to play streaming video once, but after reboot there was no lucky at
all. Could this be somehow memory related bug?

Comment 34 Andre Klapper 2010-03-01 21:49:22 UTC

No, as bug 8043 is not fixed in 3.2010.02-8, but the version after that has not
been published yet...