August 18, 2012, 09:50:33 am
News:
Pages: 1 ... 8 9 [10]
 91 
 on: April 09, 2012, 08:45:48 am 
Started by pfft2001 - Last post by pfft2001
That's... really odd.  Since the only place I've ever recorded to was an 8GB SDHC card.

When you mount it now as FAT32, does dmesg give you any errors at all?  How about when you go to setup the recording?

Is it possible you have the little read-only toggle flipped?  (I always forget they have those...)

Well, I am able to record to the card - via the scheduler  and by using SQLITE3 to modify the path name stored in the database.  That is, I use SQL (the "update" command) to change it to: /media/SD-card/foo.mp4 and then the scheduled recording runs, creating a file on the SD card.  So, the problem is in the GUI, not in the underlying mechanics.  And it is obviously not a read-only problem.

Further, I'm sure that it does work - out of the box - it's just that somehow my GUI has gotten "wedged".  I've tried pressing the Xim key and hitting "refresh", but it doesn't help.  It seems like some kind of "refresh" operation is needed - something to make it re-scan the devices and re-populate the menu.  And, as I mentioned, I even tried rebooting, but it still didn't show up in the menus.

P.S.  As far as I can tell, there aren't any errors in "dmesg" (when the card is formatted FAT).  Of course, the logs are so chatty that it is sometimes hard to tell what's an error message and what isn't...

P.P.S.  Just out of curiosity, any idea why it didn't work as EXT2?

 92 
 on: April 08, 2012, 10:00:47 pm 
Started by pfft2001 - Last post by ChadV
That's... really odd.  Since the only place I've ever recorded to was an 8GB SDHC card.

When you mount it now as FAT32, does dmesg give you any errors at all?  How about when you go to setup the recording?

Is it possible you have the little read-only toggle flipped?  (I always forget they have those...)

 93 
 on: April 08, 2012, 10:18:37 am 
Started by pfft2001 - Last post by pfft2001
As you all know, I have long championed recording only to the network, since the USB doesn't work at all and the network is just more convenient overall (since you can get to the files from anywhere on your network).  However, today, while trying to debug/fix a long lingering problem, I decided to try recording to SD card again.  I ran into a couple of issues:

1) Since the card that I chose to use - an 8G SDHC card - had been partitioned in a funny way as part of another experiment (with the RPi, as it turns out), I repartitioned it and formatted it (on another Linux system) with "mke2fs".  I know that the OSD is most happy with media formatted FAT32, but I have been assured, by Neuros Tech Support (on the phone - back in the early days when they actually had phone tech support) that EXT2, being Linux's "native" file system, would work just as well - in fact, better in some ways than FAT32.  Well, the problem I ran into was that when I inserted the card, it failed to mount it.  I could tell from "dmesg" that it saw the card, but then generated some error messages indicating that it was trying to mount it as if it were FAT and it failed.  When I reformatted the card with "mkdosfs", it then worked as expected in the OSD.  Strange, eh?  Maybe that could be fixed in a future life...

2) (The real reason for this posting).  Once I had the card in the OSD and auto-mounted, I could see it as a choice in the Play.Browse dialogs, but *not* (and this is the truly strange part) in the Record.Schedule dialogs.  I could not find any way (using the GUI alone) to *record* to the SD card.  The only choices given were all of my network shares as well as the options for mounting new network shares.  There was nothing for either USB or SD-Card.

Now, two things:

....a) I seem to remember hitting this problem once long ago, before I had compiled SQLITE3, and finding some weird fix - some obscure option buried somewhere in the GUI.  I say "weird" because this is a bug, but there seemed to have been some weird workaround.  Note also that I did end up rebooting the OSD (with the SD card inserted) to see if that would fix anything, but it did not.

....b) I was able to fix this by brute force, for my scheduled recording(s), using SQLITE3 to modify the database directly.  This was a lifesaver, but this is obviously not ideal.  Also, I could still find no way (using the GUI) to do an "on the fly" recording to SD.  Note: I think I tried just about all the places in the GUI where you can set this; I even tried Tools -> Settings -> Default Recording -> SaveTo/Edit - but again, the only options presented were the network-oriented ones.

In conclusion, any help/advice anyone can give would be greatly appreciated.



 94 
 on: April 07, 2012, 02:56:12 pm 
Started by ima999 - Last post by heyrick
The problem, I believe, was a change in RAM used...  The manufacturing line made a substitution that spec'd in, but between the USB controller and the slapdash drivers, it ended up causing a timing problem under heavy load...

Ah. The sort of tiny quirky thing that makes you want to bang your head on the wall and cry. Yeah, I know from programming interrupt handlers that things that seem very clear in the spec sheet can behave quite differently when flying under load. One that used to give me nighmares was high-speed interfacing to parallel ports. The SPP+, EPP, ECP, and so on were essentially due to none of them being capable of devising a decent spec. One idle moment, I looked at the USB spec. USB 1.1 isn't bad, seems to have a few things in common with IIC. USB2 is... well, I can't express my feelings in a PG-13 way. Wink Not that I really followed USB, I was looking out of interest to see why so many implementations are poor. I've a USB key here that crashes my DVD player the moment I insert it. Hard crash too, I have to reconfigure it again. The USB in the OSD is lacklustre. My older PVR (DM320 based too) would work well with some devices and fail with others. Hmm...


Quote
Disk Utility

Well, there's an inspired name for you!


Quote
Or just remove the port on that run and sell it as a slightly cheaper ($2?) ethernet-less model.

That would be then a Model A+, no? (the real 'A' has half as much RAM)

Shame this happened, but I'm glad they're going for a run of Model Bs. Given the small price difference, I wonder how many people would actually buy the Model A? I would like to run a server, so I'll be going for the model B. I plan to buy a cheap ethernet cable, strip it down to two plugs with about ten centimetres of wire between. I will then mount the RPi inside my Livebox. There's loads of room, and as the RPi is light on power requirements, I ought to be able to piggyback the router's power supply without crisis. Set up a VNC server on the thing, then I can do all the setup and such from here.


What I'd really really like to do, and don't know if such software exists - is to have something that can receive AnimeNFO (192kbps MP3) or other streaming radio stations, and spit it out as a stream as 24kbps AAC+. I would then connect in (from work) on my mobile phone. The reason for this is that I have a monthly allocation of 500MiB, and 192kbps runs to around 84MiB/hour! 24kbps runs to around 10MiB/hour. Quite a difference. Work is noisy, so the quality loss is no big deal. Not worried about copyright issues, it's a downconvertor for my own private use.


Best wishes,

Rick.

 95 
 on: April 07, 2012, 08:36:04 am 
Started by ima999 - Last post by ChadV
Well...that's a new one on me! Shocked Do you (or ChadV?) happen to know the serial numbers? That would say whether we're on a losing track or not with the unit in question.
Do you know what the problem was? I just figured USB problems were down to a rather slapdash driver implementation. Wink

I don't have an S/N range.  The problem, I believe, was a change in RAM used...  The manufacturing line made a substitution that spec'd in, but between the USB controller and the slapdash drivers, it ended up causing a timing problem under heavy load...

I'm sure your Mac has something similar to "scandisk", the things that that is supposed to fix are the sorts of things that incorrectly managed discs can develop...

Disk Utility

Rick - as far as I know (based only on reading the Rpi forum) - that is what they did (fixed them, rather than just do it all over).  I have to admit that my first reaction was the same as yours - i.e., just do it over - but presumably, they know best.

Or just remove the port on that run and sell it as a slightly cheaper ($2?) ethernet-less model.

 96 
 on: April 06, 2012, 07:46:53 pm 
Started by ima999 - Last post by pfft2001
Rick - as far as I know (based only on reading the Rpi forum) - that is what they did (fixed them, rather than just do it all over).  I have to admit that my first reaction was the same as yours - i.e., just do it over - but presumably, they know best.

 97 
 on: April 06, 2012, 06:23:01 pm 
Started by ima999 - Last post by heyrick
ima999 - fair point. I guess it's the programmer in me coming out that I'd want to get to the bottom of things.
I hope SD works for you.

Oh, and one other thought. If you have pulled the USB stick out without ejecting (ie if the OSD crashes), it might be worthwhile giving it a format before you use it again, as we can't say in what state the disc "structure" would be. I'm sure your Mac has something similar to "scandisk", the things that that is supposed to fix are the sorts of things that incorrectly managed discs can develop...


Best wishes,

Rick.

 98 
 on: April 06, 2012, 06:16:44 pm 
Started by ima999 - Last post by heyrick
There was a known problem where a certain batch (set of serial numbers) of units had a bad USB port.  I had one such unit - confirmed here via the serial # that is was from that production run

Well...that's a new one on me! Shocked Do you (or ChadV?) happen to know the serial numbers? That would say whether we're on a losing track or not with the unit in question.
Do you know what the problem was? I just figured USB problems were down to a rather slapdash driver implementation. Wink


RaspberryPi - I really hope they did not demand the boards be manually corrected. The assembly is automated for God's sake - it would be cheaper and quicker to set up and bash out another 10k boards (and some Hong Kong vendor drop the originals on unsuspecting punters via eBay) than to actually unsolder the bad part and fit a good one, then test it, one by one by hand...


Best wishes,

Rick.

 99 
 on: April 06, 2012, 03:36:23 pm 
Started by ima999 - Last post by ima999
Rick - Thanks for the suggestion.
Here's my dilema.

I purchased the unit a few years ago with hopes to replace my original 2/2 unit.
I couldn't get it to work correctly originally, and I assumed it was because I was trying to use an attached hard drive.
I then set it aside for a long time and retried it later with other drive options -- this never really worked so I set it aside for another long time
Now I decided to either get it working or toss it (it mocks me every time I see it in the cabinet)
And wouldn't you know it - I haven't gotten any smarter and the firmware updates didn't make the unit any smarter (to cover for my inabilities).

So all told I've spent WAY too many hours trying to get the unit to work.
I'm willing to give the SD card a try but that's about it - why, because sometimes you just gotta stop to get ahead. 
I know I've spent good money on this product - but if it can't work with features that it offers then I guess it's not for me.
I really liked the original 2/2 product and wanted to "upgrade" to use some of the new features and add some simplicity to my life..... I haven't found that yet.
If only the world would produce products that marketing sold.

 100 
 on: April 06, 2012, 01:50:02 pm 
Started by ima999 - Last post by ChadV
(*) For those of you not familiar, they had a batch of boards (10K units) manufactured, but the idiots put the wrong kind of ethernet jack on the board.   The problem was caught after the boards were shipped back to the UK for inspection, after which they had to be shipped back to China, un-soldered, re-soldered, and shipped back to the UK again.  And that's not even mentioning the fun of lining up a source for the new jacks (qty: 10K).  All under extreme time pressure from a lot of people who were watching a late project get later.


Funnily enough, that's part of the reason why the OSD2 never went anywhere...  All the dev boards had disconnected HDMI audio pins.

And yeah, I forgot about that earlier USB batch.  We did implement some fixes in firmware, but there was only so much we could do.  Since even the good units still could bottleneck pretty easily, we just suggested SD over USB where possible, and fixed any units where the owner was not okay with that solution.  (Back when we had units.)

Pages: 1 ... 8 9 [10]