| LinHES Forums http://forums.linhes.org/ |
|
| Seek (fastforward/rewind) not working in sticky mode on OSX http://forums.linhes.org/viewtopic.php?f=17&t=14873 |
Page 1 of 1 |
| Author: | ssteward [ Mon Apr 09, 2007 2:55 pm ] |
| Post subject: | Seek (fastforward/rewind) not working in sticky mode on OSX |
Hi, My sticky seek has stopped working after about a year of performing perfectly. It jumps forward about 5-10 seconds every few seconds of seeking seemingly regardless of what speed the seek is set to. The FE logs show: Code: 2007-04-09 21:38:32.147 AFD: SeekReset(2433, 0, do flush, don't discard) 2007-04-09 21:38:32.147 write -> 12 50 QUERY_FILETRANSFER 32[]:[]REQUEST_BLOCK[]:[]524288 2007-04-09 21:38:32.147 AFD: SeekReset() flushing 2007-04-09 21:38:32.308 NVP: Waiting for prebuffer.. 3 AAAAAAAAAUUAUAAAAAAAAAAAAAAAAAA 2007-04-09 21:38:32.585 read <- 12 6 524288 2007-04-09 21:38:32.585 Read(): reqd=524288, rcvd=524288, rept=524288, error=0 2007-04-09 21:38:32.585 reads allowed (524289 32768) 2007-04-09 21:38:32.585 write -> 12 50 QUERY_FILETRANSFER 32[]:[]REQUEST_BLOCK[]:[]524288 2007-04-09 21:38:32.595 AFD: DoFastForward(2478 (2434), don't discard frames) 2007-04-09 21:38:32.595 Dec: DoFastForward(2478 (2434), don't discard frames) 2007-04-09 21:38:32.916 NVP: prebuffering pause 2007-04-09 21:38:32.916 NVP: Waiting for prebuffer.. 0 AAAAAAAAAAAAAAuAAAAAAAALAAAAAAA 2007-04-09 21:38:33.045 read <- 12 6 524288 2007-04-09 21:38:33.045 Read(): reqd=524288, rcvd=524288, rept=524288, error=0 2007-04-09 21:38:33.045 write -> 12 74 QUERY_FILETRANSFER 32[]:[]SEEK[]:[]0[]:[]37946108[]:[]0[]:[]0[]:[]37180984 2007-04-09 21:38:33.062 read <- 12 14 0[]:[]37946108 2007-04-09 21:38:33.062 AFD: SeekReset(2481, 0, do flush, don't discard) 2007-04-09 21:38:33.062 write -> 12 50 QUERY_FILETRANSFER 32[]:[]REQUEST_BLOCK[]:[]524288 2007-04-09 21:38:33.062 AFD: SeekReset() flushing 2007-04-09 21:38:33.489 read <- 12 6 524288 2007-04-09 21:38:33.489 Read(): reqd=524288, rcvd=524288, rept=524288, error=0 2007-04-09 21:38:33.489 reads allowed (524289 32768) 2007-04-09 21:38:33.489 write -> 12 50 QUERY_FILETRANSFER 32[]:[]REQUEST_BLOCK[]:[]524288 2007-04-09 21:38:33.500 AFD: DoFastForward(2526 (2482), don't discard frames) 2007-04-09 21:38:33.500 Dec: DoFastForward(2526 (2482), don't discard frames) 2007-04-09 21:38:33.556 NVP: Waiting for prebuffer.. 1 AAAAAAAAAAAAAAUAAAuAAAAAALAAAAA 2007-04-09 21:38:33.898 read <- 12 6 524288 2007-04-09 21:38:33.898 Read(): reqd=524288, rcvd=524288, rept=524288, error=0 2007-04-09 21:38:33.899 write -> 12 74 QUERY_FILETRANSFER 32[]:[]SEEK[]:[]0[]:[]39000036[]:[]0[]:[]0[]:[]38077180 2007-04-09 21:38:33.907 read <- 12 14 0[]:[]39000036 2007-04-09 21:38:33.907 AFD: SeekReset(2529, 0, do flush, don't discard) 2007-04-09 21:38:33.907 write -> 12 50 QUERY_FILETRANSFER 32[]:[]REQUEST_BLOCK[]:[]524288 2007-04-09 21:38:33.907 AFD: SeekReset() flushing 2007-04-09 21:38:34.197 NVP: Waiting for prebuffer.. 2 AAAAAAAAAAAAAAUAAAUAAAAAAAAAAAA 2007-04-09 21:38:34.316 read <- 12 6 524288 2007-04-09 21:38:34.316 Read(): reqd=524288, rcvd=524288, rept=524288, error=0 2007-04-09 21:38:34.316 reads allowed (524289 32768) 2007-04-09 21:38:34.316 write -> 12 50 QUERY_FILETRANSFER 32[]:[]REQUEST_BLOCK[]:[]524288 2007-04-09 21:38:34.328 AFD: DoFastForward(2574 (2530), don't discard frames) 2007-04-09 21:38:34.328 Dec: DoFastForward(2574 (2530), don't discard frames) 2007-04-09 21:38:34.706 read <- 12 6 524288 2007-04-09 21:38:34.706 Read(): reqd=524288, rcvd=524288, rept=524288, error=0 2007-04-09 21:38:34.706 write -> 12 74 QUERY_FILETRANSFER 32[]:[]SEEK[]:[]0[]:[]40254560[]:[]0[]:[]0[]:[]39163876 2007-04-09 21:38:34.715 read <- 12 14 0[]:[]40254560 2007-04-09 21:38:34.715 AFD: SeekReset(2577, 0, do flush, don't discard) 2007-04-09 21:38:34.715 write -> 12 50 QUERY_FILETRANSFER 32[]:[]REQUEST_BLOCK[]:[]524288 2007-04-09 21:38:34.715 AFD: SeekReset() flushing 2007-04-09 21:38:34.837 NVP: Waiting for prebuffer.. 3 AAAAAAAAAAAAAAUAUAUAAAAAAAAAAAA 2007-04-09 21:38:35.194 read <- 12 6 524288 2007-04-09 21:38:35.194 Read(): reqd=524288, rcvd=524288, rept=524288, error=0 2007-04-09 21:38:35.194 reads allowed (524289 32768) 2007-04-09 21:38:35.194 write -> 12 50 QUERY_FILETRANSFER 32[]:[]REQUEST_BLOCK[]: The BE log for the same period shows: Code: 2007-04-09 21:37:51.894 EITScanner: Added 1 EIT Events
2007-04-09 21:37:52.342 EITScanner: Now looking for EIT data on channel 1 2007-04-09 21:37:53.009 DVB#0 DVB SI Table Parser Started 2007-04-09 21:39:00.417 EITScanner: Added 1 EIT Events 2007-04-09 21:39:00.425 Reschedule requested for id -1. 2007-04-09 21:39:00.741 Scheduled 35 items in 0.3 = 0.17 match + 0.15 place 2007-04-09 21:39:01.064 EITScanner: Now looking for EIT data on channel 14 2007-04-09 21:39:01.712 DVB#1 DVB SI Table Parser Started none of which seems relevant to the failing seek. The FE jumps forward and back in 10 min blocks just fine; the FE running on the BE seeks fine with the same programme. I haven't changed anything on my network or my myth set up. Can anyone suggest what the problem might be? Thanks -S |
|
| Author: | nigelpearson [ Mon Apr 09, 2007 6:35 pm ] |
| Post subject: | |
I don't use the FFWD (seek) at all, so I just did a test with a 0-19-fixes mac client. On a MacBook, seeking forward at 3X was using 60% of one CPU, and 70% of the other. At 5X or faster, it was using 30% and 40%. It looks like this is a big CPU drain. The only obvious thing in the log is the 'Waiting for prebuffer...' messages. I frequently get this on slower Macs - it seems that transferring the network data is a high priority task, and it sometimes causes skipping in MPEG decoding. Have you maybe installed something extra on the Mac that might be using CPU in the background? Or are the current recordings you are watching now at a higher bitrate than those from a few weeks ago? |
|
| Author: | ssteward [ Tue Apr 10, 2007 5:14 am ] |
| Post subject: | |
The recordings are the same so I guess it could be something I've installed on the Mac. I have added a lot to it in recent weeks. I'll take off any unnecessary apps. Oddly it's happend after I took the RAM from 512MB up to 2GB. Everything else now flies as a result of more RAM but this occurred around that time (btw, the sticky programme list scrolling has always been a problem since day 1). Is there a recommended way to allocate a higher priority to OSX Myth FE when it's the currently focussed app? I can see lots of conflicting advice about messing with OSX nice values in general on the web and wondered what your view was. Regards -S |
|
| Author: | ssteward [ Wed Apr 11, 2007 4:48 pm ] |
| Post subject: | |
Nigel, the problem has fixed itself after about a week. It works fine now. I haven't rebooted the BE but the FE has be restarted a few times but no software changes in that time. Odd but pleased it's back to health again. Thanks again. Btw, how do you manage without using seek? Btw2, and quite off-topic, do you know of any tool for OSX that'll allow the in-built IR receiver to receive IR commands from other remote controls? Ideally allowing the new IR signals to map to arbitrary key presses. It would seem feasible but I can't find anything to do it. Of course this would allow a learning remote to simulate the keyboard and would be great for Myth. -S |
|
| Author: | nigelpearson [ Thu Apr 12, 2007 1:15 am ] |
| Post subject: | |
ssteward wrote: Odd but pleased it's back to health again. Very odd. Was this wireless? Interference could cause that, but its unlikely.Quote: Btw, how do you manage without using seek? We use JUMP almost exclusively. Arrow Down is forward 5min, Right is 30sec. Ad breaks are 5 or 7 right clicks.It seems that the frontend is much more efficient jumping than it is FFWDing (i.e. seek at 2x or 3x or 5x or whatever). Quote: Btw2, and quite off-topic, do you know of any tool for OSX that'll allow the in-built IR receiver to receive IR commands from other remote controls? None that I know of. I am not sure it is possible under the Mac OS yet (it may be possible under Linux/LIRC on your Mac).
I did find some code that may help me work out if it is even possible, though: http://www.osxbook.com/book/bonus/chapter10/iremoted |
|
| Author: | ssteward [ Thu Apr 12, 2007 5:20 am ] |
| Post subject: | |
No, it's not wireless. (I spent hours and hours burying 100m of cat5 in the wall and ceiling of my flat to get round flaky wireless, banish the noisy servers into my 'server cupboard' and enjoy gigabit networking.) I see. I use jump a lot too but need seek, mainly for moving back less than 30secs but often for scanning the news at high speed to see if there are any segments I want to watch. But back to the IR point: the page you gave looks promising. If the on board IR could receive arbitrary IR patterns/commands then it could be programmed to learn commands from a random old remote and these could be used to invoke HID key presses. Then the learning remote used for the rest of the AV set up could learn the commands from the old remote too. Then a much fuller set of Myth key presses could be used. I guess you've seen remote buddy from http://www.iospirit.com/. This only uses the apple remote's commands but allows these to control other applications. Then there's iRed and iRed lite (http://www.filewell.com/iRed/). The lite version is similar to remote buddy. The full version uses a separate IR module with a transmitter that allows the Mac to become a virtual remote to control other devices. Still, neither of these is very useful in a Myth context. |
|
| Page 1 of 1 | All times are UTC - 6 hours |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|