Author Topic: BUG v1.01.11 - Must power cycle to play video  (Read 25201 times)

January 25, 2010, 12:47:49 AM
Reply #15

gondor

  • Newbie

  • Offline
  • *

  • 20
I am using version 0.3.4.1 from here http://wdtvforum.com/main/index.php?topic=3554.0
I do not recommend using custom firmware unless you have some Linux experience.

Tom

February 15, 2010, 09:26:18 PM
Reply #16

Pandar

  • Newbie

  • Offline
  • *

  • 14
I have the exact same problems, some days I can stream various videos for hours without any stuck loading problems and on other days I have to power cycle every 20-30minutes. It's very frustrating trying to watch a series this way. This didn't happen with my 1st month owning the device in December. It started to happen once in awhile in my 2nd month, and in my 3rd month it happens almost every day. Very disappointed. Is there still no permanent fix, is WD even aware of this problem?

February 16, 2010, 12:18:09 PM
Reply #17

gregvolt

  • Newbie

  • Offline
  • *

  • 22
I also have the same problem. the spinning waiting indicator. It usually happens after i try to fastforward and then try to resume normal play.  Then i get the message unable to play this video file.   It is annoying at a minimum

February 16, 2010, 04:04:54 PM
Reply #18

Pandar

  • Newbie

  • Offline
  • *

  • 14
I also have the same problem. the spinning waiting indicator. It usually happens after i try to fastforward and then try to resume normal play.  Then i get the message unable to play this video file.   It is annoying at a minimum
When it starts to happen every 20-30mintues it's downright infuriating. I can barely 1 episode of a show let alone a movie now.

February 16, 2010, 05:32:18 PM
Reply #19

GuyWD

  • Jr. Member

  • Offline
  • **

  • 88
I'm sorry you guys are having this problem. We're aware of this, but it's hard to reproduce consistently. Does it seem like it happens more often with specific codecs or containers? Any clues that you can offer to help track this down would be much appreciated.

February 16, 2010, 11:03:10 PM
Reply #20

trehouse

  • Newbie

  • Offline
  • *

  • 17
Happens within my .avi (not sure if divx or xvid) tv programs which come from many different sources. Pretty consistent issue. No MP3's or other video formats are displaying this issue for me.

Since I didn't rip them I can't be sure if there weren't issues with that however I noticed that all of these rips are only fair quality.

Thanks for looking into this one.

BTW, IMO you need to modernize the GUI so that detailed info can be displayed before anything else.  8)

Obviously, from reading this thread this is a nasty problem with some more impacted then others and therefore I don't want to take anything away from those whose WDTV-Live units are always impacted.
« Last Edit: February 17, 2010, 07:14:21 AM by trehouse »

February 17, 2010, 03:49:58 AM
Reply #21

gregvolt

  • Newbie

  • Offline
  • *

  • 22
It happens with every format that i use. avi, wmv, mpg. if you want to reproduce it constantly, i could send you my unit! it happened to me about 5 times last night in 20 minutes. and it usually happens after i try to fastforward a couple of times.  sometimes it happens when i try to play a video straight from the menu except in that case i just get the spinning circle and no video at all. As with the other guys, it worked fine when i first got it but then it started and got worse and worse until now it happens constantly.

February 17, 2010, 03:54:53 AM
Reply #22

gondor

  • Newbie

  • Offline
  • *

  • 20
@GuyWD: It happens with official and custom firmware alike, and is not related to file/container type. After cca 30 minutes since power on, the bug appears. The only thing that helps is restarting DMARender and PICRender (when running custom firware). After that wdtv runs correctly until next complete power down.

Interesting note: if DMARender and PICRender are restarted before 30 minutes since power on (before the bug appears) - than wdtv runs correctly. My best guess is that something is wrong with order of starting of those two processes, or they should wait for some other process to get started first.

February 17, 2010, 09:37:49 PM
Reply #23

Pandar

  • Newbie

  • Offline
  • *

  • 14
@GuyWD: It happens with official and custom firmware alike, and is not related to file/container type. After cca 30 minutes since power on, the bug appears. The only thing that helps is restarting DMARender and PICRender (when running custom firware). After that wdtv runs correctly until next complete power down.

Interesting note: if DMARender and PICRender are restarted before 30 minutes since power on (before the bug appears) - than wdtv runs correctly. My best guess is that something is wrong with order of starting of those two processes, or they should wait for some other process to get started first.

Would this be fixable by a custom firmware if WD does not address this issue soon? I usually just leave it off now as I am tired of having to get up and go over to the unit to power cycle it every 20-30minutes.

February 17, 2010, 11:58:00 PM
Reply #24

gondor

  • Newbie

  • Offline
  • *

  • 20
Would this be fixable by a custom firmware if WD does not address this issue soon? I usually just leave it off now as I am tired of having to get up and go over to the unit to power cycle it every 20-30minutes.

Yes. There is a workaround that bug by editing S99post-init script to restart  DMARender and PICRender.

However, first someone has to verify that this really helps and resolves the issue. I have done it and it helps, but one success is not a proof. Here is the procedure:

<Linux experience required>

1. Install custom firmvare 0.3.4.1 from http://b-rad.geg0r.de/

2. Verify that the bug is still active

3. Login as root to WDTV (by telnet) and issue 2 commands :

killall DMARender
<wait 2 seconds>
killall PICRender

4. Verify that bug is no longer present.

5. Optionally, revert back to official firmware

6. Report here so I can suggest a patch to custom firmware

Tom

February 19, 2010, 09:20:58 AM
Reply #25

Pandar

  • Newbie

  • Offline
  • *

  • 14
Would this be fixable by a custom firmware if WD does not address this issue soon? I usually just leave it off now as I am tired of having to get up and go over to the unit to power cycle it every 20-30minutes.

Yes. There is a workaround that bug by editing S99post-init script to restart  DMARender and PICRender.

However, first someone has to verify that this really helps and resolves the issue. I have done it and it helps, but one success is not a proof. Here is the procedure:

<Linux experience required>

1. Install custom firmvare 0.3.4.1 from http://b-rad.geg0r.de/

2. Verify that the bug is still active

3. Login as root to WDTV (by telnet) and issue 2 commands :

killall DMARender
<wait 2 seconds>
killall PICRender

4. Verify that bug is no longer present.

5. Optionally, revert back to official firmware

6. Report here so I can suggest a patch to custom firmware

Tom
Would it be difficult to learn to do this? I am willing but have no linux or telnet experience.

February 19, 2010, 10:09:13 AM
Reply #26

gondor

  • Newbie

  • Offline
  • *

  • 20
@Pandar: I do not recommend this experiment to someone without previous Linux
experience.
 

February 19, 2010, 11:44:08 AM
Reply #27

gregvolt

  • Newbie

  • Offline
  • *

  • 22
I have some linux experience and i tried it but i wasn't able to figure out how to get it to read my network drive, only my pc. anyway.. after the video froze i did the killalls and then reverted back to official firmware as you said was optional. and the freezing began again. i would have stayed with the homebrew but like i said.. i couldnt get it to see my network drive. maybe i just need to play with it.. the weekend is here.. so i may.

February 19, 2010, 01:34:56 PM
Reply #28

gondor

  • Newbie

  • Offline
  • *

  • 20
@gregvolt: Misunderstanding, what I wanted to say is: verify that bug is no longer present while still running custom firmware. So the point is that bug is common for both official and custom firmware; but fix (read workaround the bug) is (if it works) possible only for custom firmware as the official one does not have telnet server incorporated.

Once again : killing both processes should fix the bug for custom firmware but ONLY until complete power off (unplug). Reverting to official firmware requires power off and the bug reappears. The purpose of this experiment is to verify the fix in a 'controlled environment'. That is why I suggest specific firmware and strict testing procedure, otherwise we can get false positive or false negative result. I believe the above post is such case, or I could be completely wrong in my theory. We will see... 

NB: English is not my native language so I have difficulties explaining subtle details.

Tom

February 19, 2010, 04:08:59 PM
Reply #29

gregvolt

  • Newbie

  • Offline
  • *

  • 22
@Tom. Your english is very good, dont worry. I will retry when i get some time and let you know.  I did notice that after i killed the processes, i had to power off (using remote) and restart to continue using the device but i didnt go any further from there as far as testing.