Not just another Linux blog ...

We received a good bit of feedback in the last 24 hours from users trying out the PCTV 340e driver, and I am happy to say that 100% of it has been positive. There were a few issues with new users not familiar with compiling v4l-dvb from source code, but everybody who has tried it so far has reported success.

Our friends at Xceive for providing support on the xc4000, in addition to providing licensing to freely redistribute the firmware (we will be working on getting that bundled into Ubuntu and other distributions in the coming weeks).

PCTV Systems, and in particular Rainer Miethling for providing sample hardware as well as technical information about the PCB layout.

Davide Ferri, for providing some code attempting to port the xc5000 driver to work with the xc4000

It’s probably also worth pointing out that this project was not paid for by any of KernelLabs customers (and in fact, KernelLabs actually *spent* money to buy a DVB generator so I could complete the project). These are not trivial projects (this board took about 50 hours to get working). So if you find this work useful, feel free to show your support via Devin’s LinuxTV Support Fund.

Anyway, for those of you who were kind enough to do testing, please keep an eye on the blog over the next couple of weeks, since I will be doing some cleanup and it would be worthwhile for you to try the final tree *before* it goes into the v4l-dvb mainline.

90 Comments for PCTV 340e feedback

katja

tried to compile v4l, make config then make at some point following error :

I have problems using dvbsnoop with my 340e PCTV device. I am able to watch digital TV using Kaffeine and do channels scanning using w_scan, but dvbsnoop seems to be not working.
Here is output of “dvbsnoop -s feinfo” command:
———————————————————
FrontEnd Info…
———————————————————

I’m actually not familiar with dvbsnoop. But from my experience with other tools such as femon, did you remember to use the “-r” argument when you ran “tzap”?

I’ll have to look closer at dvbsnoop before I could offer more advice. Frankly I cannot see how this could possibly be specific to the 340e, since it is using the dib7000 demod frontend driver which has been around for years.

Hi Karol, I have Kaffeine and w_scan installed. Could you please tell me how you make the Pinnacle 340 e SE device working for digital TV? I would appreciate it very much because the internet connection is not good enough to watch Euro Cup 2012. Thank you!! (I am using Ubuntu btw…)

Hello everyone,
I’m using Mandriva 2010.0 and under a 2.6.31.6-desktop586-1mnb kernel with the kernel source installed, and I cannot compile v4l for the following reason :
~/Software_Sources/pctv-340e-2/v4l/dvbdev.c:516: error: ‘struct class’ has no member named ‘nodename’
I have read some pages ago that compiling is impossible on 2.6.32.x kernels, therefore I find it incredible that it does not compile with all necessary requirements satisfied…
Do you have any idea?
PS : I’m a French student, so I may have some complications in order to express myself…

This is a known issue because the pctv-340e-2 tree is based off a v4l-dvb tree that is several months old. Your best bet is to wait a few days until I resync against the trunk, or look on the other pctv 340e thread where a user describes what he had to do to patch the source to work around the issue.

Hi Devin,
Thanks a lot for your so quick reply. As I have not found the comment where someone fixes the issue by patching the code, I am going to wait for the new source with a newer v4l-dvb tree to be released.
Thanks again,
Cocodidou

The analog support for the 340e will not be done in the foreseeable future. The issue is the dvb-usb driver framework lacks any analog support, and I cannot justify the thousands of dollars in man-hours that would be required to added the necessary infrastructure. This problem effects all products using the dvb-usb framework and is not specific to the 340e.

The 340e was a “side project” I did in my free time that was not for any commercial customer – nobody paid for this work. And after spending 50-60 hours on it, I don’t really have the personal interest in analog to spend the additional 100 hours that would be required to make it work.

Hi Devin,
first let me thank you for your great work. It’s really fantastic reading how you can make these things.
This is my experience, pls feel free to cut anything you find o.t. or not interesting for the blog:

I’m in Italy and working with a (not really clean anymore ) CRUX 2.5 distribution – kernel 2.6.31.5.
– No problem in compiling/installing the pack 340e-2
– when I connect my device, I have a failure, then after disconnecting/connecting for 2 or 3 times everything goes perfect.

– I like very much mplayer, so I looked for w_scan to create a channels.conf.
the compilation of w_scan failed talking about a dvb_api 5.1 problem; I copied all from pctv-340e-2-927fd2a915c4/linux/include/linux/dvb/* to /usr/include/linux/dvb/ and the compiling problems went away.

– w_scan -c it -X > channels.conf
generated a perfect conf file for my mplayer; after mv channels.conf /usr/etc/mplayer/ I then started my mplayer with mplayer -cache 1024 dvb:// and with and I can scroll all channels!!!

– I can record from my 340e simply with:

mplayer dvb://”channel name” -dumpstream -dumpfile record_1.ts
or
mencoder dvb://”channel name” -of mpeg -ovc copy -oac copy -o record_1.ts
(the channel name is at the beginning of every line in channels.conf)

– usually mplayer start opening a little bit wth audio/video out of sync, but after a couple of seconds everything run perfect.

I’m starting testing vlc, but it’s not so happy to receive signal from my device.
I also tried to pipe a stream from mplayer to vlc: I can see something, but still problems. vlc logs various things about incorrect video format etc, if it’s useful for you I can send it.

Many thanks again for our great work. I was a frustrated owner of this device, now I’m an happy user

It looks like it is finding some signals, but then those signals aren’t providing any actual MPEG data. Could you please try the regular “scan” tool as opposed to “w_scan” so we can see if this behavior is application specific?

Nobody else has reported problems with sound with the 340e. One thing to bear in mind is that unlike analog cards, with DVB-T cards the device just takes the MPEG stream and forwards it to userspace. Neither the driver nor the hardware have any knowledge of which packets contain audio versus which contain video.

You may wish to try seeing if audio is working at all from within Kaffeine (perhaps by loading a DVD). Also, you should see if the problem is specific to one frequency or whether none of the channels work (since it’s possible that the frequency table you provided during scanning has an error).

Hi Ander,
You might have no sound with Kaffeine watching TV if channels are being broadcasted with H.264/AAC (e-AC3) encoding and Kaffeine does not support e-AC3 at all. I did not find any workaround on Kaffeine about that, but I have patched my copy of FFMPEG with spectral extension support and now all of my channels work with VLC (TF1 HD, France 2 HD and M6HD especially, therefore I can still watch SD channels with Kaffeine).
Hoping I did help you
Cocodidou

I found similar as Karol, in depth either I diconnected my antenna or connected I get
(approx) Sig ~ 33500 SNR ~ 230 from the
dvbsnoop -s singal
command.

Since no (or only 1-2%) difference in the measured values on 17 dbI reception and 0 dBi reception I guess does the driver provides good value to DVB API from where the dvbsnoop read the values?
I found similar with tzap.

Do you have any solution for this? Or any idea how to measure SNR and Signal Strength from command line and build percentage statistics from them?

By the way, I don’t know how to interpret the values. What is the range of SNR and Signal Strength values?

The units for the SNR and signal statistics vary with every demodulator. This is different applications work with different tuners (because typically the application developer makes it work for whatever tuner he happens to have).

That said, i actually don’t know what the units are for the dib7700 used in the 340e. You may wish to ask the linux-media mailing list, as somebody there probably knows.

I have got a 340e yesterday, and I successfully made it works with a “patched” Debian Lenny.
I had to change the Kernel with 2.6.31.13 (not latest version of kernel) which is then patched by KernelLabs modules (if I correctyl understood what I did :-o)
I may have further problems, but I can watch TV under Linux !
That’s great!

I’ve been pretty buried in another project, and am not sure when I will be able to find the time to rebase the tree. If you cannot do the rebase locally in your own environment, then your only option at this point would be to not upgrade to Mythbuntu 10.04. For what it’s worth, there are no new MythTV features in 10.04 (they use the same version of MythTV), so you would not see any benefits in upgrading (aside from doing it “just to be running the latest software”).

I got the 340e running using kernel 2.6.32-22 (ubuntu 10.04). The only real change was the name of the array with ir key codes. The remaining conflicts are trivial to fix. I hope the other changes in mainline don’t affect the 340e code in a bad way (but everything seems to work alright).
Thanks a lot for the driver, it works like a charm here in belgium!

Just an ‘hg pull -u http://linuxtv.org/hg/v4l-dvb/‘, ‘hg merge’, resolve the conflicts (about 5 or 6 files) and do the regular ‘make && make install’. If you can’t do that, you will have to wait for Devin to update his branch. Several versions of this branch floating around online wouldn’t do much good, imho

Mmh… Try to make clean before making… 2.6.31.13 is the kernel I compiled v4l on before packaging the tarball.
Have you solved the problem this time?

Cocodidou

Mmh… Try to make clean before making… 2.6.31.13 is the kernel I compiled v4l on before packaging the tarball.
(Note that I have just cleaned the tarball when I wrote this message and re uploaded it, so you can try to re download it and compile it again it should work )
Have you solved the problem this time?

-Get the firmware “http://kernellabs.com/firmware/xc4000/dvb-fe-xc4000-1.4.1.fw” and copy to /lib/firmware

-sudo tail -f /var/log/messages

wait and plug the device in

wait

restart

Thanks to all and to Frank Duigman

galera

Sorry

– add the line “#include ” in the following files: dvb_demux.c, dvb_net.c, cpia.c, meye.c, videobuf-core.c, dmxdev.c

galera

Sorry but There has been a mistake of written to posted in the comment.

add the line “#include linux/sched.h” in the following files: dvb_demux.c, dvb_net.c, cpia.c, meye.c, videobuf-core.c, dmxdev.c

Cocodidou

Hello Devin,
I merged the PCTV 340e code in a recent V4L DVB tree and with a patch found herehttp://istvanv.users.sourceforge.net/v4l/xc4000.html
In that tree there is analog support for the xc4000 tuner and a Conexant cx25840/1/2/3 video analog to digital converter.
I would like to link these elements together in order to have support for the S Video and composite inputs which would be very useful for me.
I think that an xc4000 reset with certain init params would do the trick but I don’t know what param to pass to the xc4000 tuner to tune analog instead of digital and get the input from the Conexant cx25843 (in the dib0700_devices.c file, I will remove the line that shuts the analog DAC down if we go analog, otherwise let it).
Any idea of what I could do?
Thanks by advance
Cocodidou

If someone is interested, I can post here a TGZ I have made which contains a working v4l dvb tree which compiles without bad complains from the compiler (only some array size assignements) and contains 340e/340eSE support:http://corentin.ferry.free.fr/pctv-340e.tar.gz
Here’s the firmware:http://istvanv.users.sourceforge.net/v4l/xc4000-1.4.fw
Rename it to “xc4000.fw” and place it in the /lib/firmware directory.
I compiled v4l under 2.6.33.2 and there were no problems.
TV works!
Hoping I helped someone…

Did you install the right firmware? Did the installation complete successfully? Because there is a module missing. Try to make clean, delete the /v4l/.version file, then make, make install and copy the firmware to the /lib/firmware directory.

Because here the symbol version seems to be the cause of the problem, the only way I see yet to fix it is to reinstall the module (this is what I am telling you how to do just before).

I install the right firmware, xc4000.fw, The compilation and installation complete successfully. I make clean, delete the /v4l/.version file, change firedtv to â€œnâ€ in /v4l/.config, then make, make install and copy the firmware to the /lib/firmware directory.

But TV doesnt work, and dmesg show the error before comment.

Cocodidou

What other versions of dvb_usb did you install? What is your kernel?
Because if nothing works with my tarball your solution may be better for you, do what you have done previsouly again and enjoy TV… Don’t forget you have to “make install” the tarball and reboot the computer… And the Module.symvers file might be faulty here because it can indicate presence of symbols which don’t exist. I had problems with the kernel provided by Mandriva speaking about the 340e, so I compiled my own kernel (and it is still working). You can otherwise just reinstall your kernel…
Linux provides a Module.symvers file upon kernel modules compilation but it can be deleted and force you to recompile your kernel, eg. VirtualBox installer deleted mine. The fix I found for this is to remove the Module.symvers file from MRPROPER_FILES.

Cocodidou

Additionnaly, here it is said that the firmware was not the right and there were the same module problems. Before reinstalling your kernel, you should download the FW from here http://istvanv.users.sourceforge.net/v4l/xc4000-1.4.fw and install it as “xc4000.fw” and check that it works…

I use dvb-usb-dib0700-1.20, xc4000.fw and dvb-fe-xc4000.1.4.1.fw . My compilation works, but the problem is that I have another analogic tv card, avertv 203, that I used to watch through compostive imput, a signal of tv satelite from a decoder I have in other room.

When I used my compilation, Pctv340e work but avertv doesnt work, I watch dvb-t.
When I used your compilation, avertv 203 video composite work, but pctv340 doesnt work, I watch dvb-s through video composite.

I have to do “sudo make install” and restart each time, to watch dvb-t or composite (dvb-s).

galera

Thank you very much Cocodidou, the problem was the kernell, I reinstall and it work fine. I watch both tvs.

Thank for your dedication.

PY

I confirm Cocodidou’s tarball works.http://www.kernellabs.com/blog/?p=1279#comment-1480
TV works including scanning, tested on Kubuntu 10.04 + Kaffeine with both stock kernel and 2.6.35rc1 as well as on Ubuntu 9.10 + MythTV on a 2.6.34rc2.
The trick was to delete /v4l/.version which persists even after a make clean, change firedtv to “n” in /v4l/.config and copy firmware as /lib/firmware/xc4000.fw
Thanks to all! Just in time for the world cup

The World Cup? I won’t turn the sound on unless Vuvuzelas have been banned from stadiums. However thanks for having tested my tarball, I’ve done a Mr. Proper on it, cleaned the remaining files and when I will be able to bind sockets back, I’ll upload the tar again.
Thanks again (and don’t begin here an endless discussion on vuvuzelas I think this is not the right place)
Cocodidou

i am using vlc to view the world cup and i think there is an ption to ban from your self the vouvouzelas

start the vlc with this command
vlc –playlist-tree channels.conf
and open effects and filters under interface and you can use the equalizer to shutdown the Hz that the vouvouzelas sound use , i think is the 310 hz

Unfortunately i can’t fully subscribe to that. Using kubuntu 10.04, kernel 2.6.32-24. I googled a lot on this, tried so many versions of tarballs and firmwares, but i can’t seem to get xc4000 loading properly at startup (although plugging out and in does the trick, but not for a mythbox hidden somewhere).

It would be nice if someone could stab me into the right direction. Another thing is, i’m quite sure with the multitude of xc4000 patches spread around in a couple of (really long) threads (or comments on it), it would be nice to state where the newest patch resides and a little howto. http://istvanv.users.sourceforge.net/v4l/xc4000.html is such a site, but it’s not clear where developement is going on and where not, which versions are the newest for which purposes.

Phil, I actually had the same behavior, i.e. it worked only when plugging the device, not at start-up with device plugged in.
I eventually purchased Dvico Dual Digital PCI in my Mythbox because of this and didn’t use the 340e since June.

i used your two firmwares ( xc4000 , dvb-usb-dib0700-1.20 ) and i compiled the Cocodidou’s version of v4l with menuconfig and delete the fireTV module.

except mpeg4 ( 8hz if i understood correct ) ,i can also see the mpeg2 channels ( 7hz ( we have in greece 4 channels from 2006 that they broadcast in mpeg2 format and i can see in one of them the World Cup )
also ,i have collected some dsmeg with bugs after usage of different apps ( until now i am only using vlc for see the tv channels and ne-tv to record series )

tell me if you need my dmesgs to mail you them . thanks a lot for your effort to make this card work in linux.

Your broadcaster is wrong. MPEG-4 HD broadcasting is probably done with the EAC3 audio codec instaed of standard AC3. EAC3 is not supported by Kaffeine or xine. Nevertheless, VLC with a patched ffmpeg can do the trick (works for me, I have a patched source tarball I made which I keep so I can reinstall it easily).

In order to get analog support working with that stick, the enitre dvb-usb framework would need to be extended to support analog, something which we cannot justify the huge amount of work and expense to do (around 100 hours of development).

Gloups… 100 hours is a lot of time. But what I’ll do is to use the existing Conexant driver (the right driver is already in the v4l tree) and link it to the dib0700 driver (like it is done for the xc4000). Still, like in Windows, I’ll have to shut the tuner down in order to switch between AV and digital RF tuning (and when nothing is in use if possible). I’ll think myself about that the next few days.
I don’t hink this is a good idea to extend the dvb-usb framework to analog as it is DVB (so Digital, not Analog) and as you said it would require a lot of work.
Thanks
Cocodidou

The problem is not the Conexant driver; of course I would reuse the existing cx25843 driver. The issue is the dib0700 driver, and how there’s currently no V4L infrastructure at all to support it (both in terms of handling the ioctls and processing the USB data stream).

And in this context when I say “dvb-usb”, I don’t mean the DVB framework in general. “dvb-usb” is a common driver which is designed to support a variety of different USB bridges, including the dib0700 found in the 340e.

Hello Devin,
Of course I have seen the problem. What I’m currently trying is to merge the code from the dib0700 driver to the cx25843 driver by including some parts of the dib0700 driver (where the 340e is) into the cx25843 driver. This is complicated, I think it won’t succeed but still I would have tried.

Why don’t PCTV Systems, as some others manufacturers do, develop open-source drivers? Once there is a patent on a product you can develop open-source drivers for it if you want with no risk of being copied by the concurrency.
Now that I’m on holidays (since 2 weeks now!!!) I have the time to spend 100 hours on developing analog support for this board…

Thanks again
Cocodidou

Devin Heitmueller

Hello Cocodidou,

Code cannot really be ported from cx25843 to dib0700, since cx25843 is a video decoder component and dib0700 is a USB bridge. They serve completely different functions.

Hauppauge/PCTV do quite a bit to support open source drivers (in fact their developers have unofficially contributed more code to v4l-dvb than any other vendor). They provide free hardware to open source developers, answer questions about the hardware designs, and apply pressure on the chipset vendors to make documentation available to allow GPL drivers to be written.

However, supporting Linux officially would have considerable financial consequences. Linux users represent less than 1% of all units sold, so the additional costs of paying a developer to write drivers for a whole different Operating System, as well as the additional costs of all the support calls would make it non-profitable. Also, in many cases the quality of the applications themselves tends to be poor (something which is outside the hands of the driver author), so now they would be forced to support all the bugginess in Kaffeine, tvtime, MythTV, VLC, etc (and have the hardware returned when customers cannot get it to work).

And regarding your assertion that they could rely on “patent protection”, this doesn’t really help. Many of the devices are based on chipsets which are also used by competitors, so as soon as they write the driver for one chip, now not only their product works under Linux but all the others do as well. For example, although 80% of the drivers for the United States standards (ATSC/ClearQAM) were written by two Hauppauge employees, they are used by cards by KWorld, Avermedia, Dvico, and a host of other competitors. The Hauppauge employees contributed hundreds of hours and thousands of lines of code to make their products work, and then a few users came along and added 10-15 lines of code so that the competitor boards would work. Seem fair?

Anyway, there will still be ongoing work to support the community, but I wouldn’t expect any sort of official support anytime soon.

Devin

Cocodidou

Hello back Devin,
Far from me this idea to have an official Linux driver for the 340e (I already make computations about financial consequences for companies . Sorry for that but I wasn’t aware that Hauppauge and PCTV employees did a lot of work, I thought that only volunteers developed the framework. Anyway, the “common v4l2 interface for dvb-usb” as said in a LinuxTV discussion is very difficult to plan.

Cheers,
Cocodidou

Massimiliano Adamo

Devin,
I must argue with you ^_^ Sorry ^_^
IMHO it’s not entirely wrong what you’re saying, but we could extend and apply your point of view, for any device that we see in the market.
But, in fact, we have vendors producing drivers for linux, and we have vendors NOT producing such drivers.
Who is the “low-minded” between the manager working in Nvidia and the manager working in Pinnacle? Is nvidia wasting its money by producing good drivers?
As far VLC is concerned, it is widely used, it runs on Windows, Leopard and Linux.
I rarely use Windows and Leopard, but as I see many people use VLC, either in Leopard, and in Windows.
I wouldn’t say “it’s buggy software”. It is as good, and as bad, as many other software. But it has much more feature than any other similar software has.
Believe me, you can even make a Mojito with VLC! It’s hard to say “VLC is buggy”.
Again, who’s the low-minded between the user running VLC and the user running itune or Windows Media Player?

The same for Kaffeine: I don’t use KDE, but Kaffeine works. Where is the problem with Kaffeine?

Last and no least, sorry to say this, but you tend to say “problem is on the software which is outside of hour hands”. But, in fact, those software you’re speaking about, is running properly. I suspect 99% of PCs in the world have VLC installed and users are very happy with it. But your driver, since 6 months, isn’t compiling and it’s working only 50% (analog won’t work).

just my point of view ^_^

Cocodidou

Massimiliano Adamo,
Sorry but I must argue with you too. You are just saying that Devin’s driver does not compile. But in fact it does, and here’s the “task” if I can say so of a Linux user, to adapt the software to his environment. Don’t always wait for volunteers or manufacturers to develop drivers for YOUR configuration (if Pinnacle wants to develop only for Windows, nobody can force them to do so for Linux), that’s why I have made a tarball (don’t tell me I’m selfish but it was primarily intended for my personal use, I was not motivated enough to publish it but I still did). You can make also your tarball if you want. That would probably meet your requirements.
But what I expect from manufacturers is just to open the source of their drivers (my sentence “Why doesn’t PCTV develop open-source drivers” was just meaning that), so that users could improve them and port them to Linux easily. Then there would be no extra work, no extra money to be required from the manufacturers.
Then comes the VLC problem. VLC is not buggy when you download and compile stable releases without modifying them. If you download beta or unstable versions, or you modify the source so it does compile with your configuration, then it might become unstable and buggy.
It’s also that, open-source software….

Massimiliano Adamo

Cocodidou,
I know the driver is compiling (it compiled on my box). But – at least – is far from perfect.
What I wanted to say is:
-> don’t blame other code, because – maybe – you have trouble with your code. It’s not fair blaming other people work, expecially when those people can’t answer to you.
It makes no sense blaming a widely used software such as VLC, to say that it’s not your fault if we get into problems by using dvb adapters.
VLC is good enough. Otherwise, please tell us which multimedia player is better then VLC, and why people tend to use it either on Leopard and on Windows.
-> if you are a vendor, you can even decide to create drivers for Linux, without providing any kind of support. I suspect that all vendors, making drivers for Linux, do not provide any kind of support for it. It’s kind of best effort support and I don’t think we can call Nvidia to get on-call support for you desktops.

IMHO: as I am a Linux user this DVB for me is rubbish, as I can’t use it from two years.

Cocodidou,
you’re wrote: VLC is unstable if you download an unstable version, and is stable if you download a stable version. ehm … ehm … I suppose I must agree ^_^ but where is the stable version of you driver? ^_^ I am kidding guys and do not take it personally. But please, be honest and say that “VLC, as a media player, is almost the master of the universe”.
And, continue to be honest, and if you get into trouble with your driver don’t blame the others and take your responisibility: you made the code and if there are trouble with your code is not VLC fault.

there are 49 cable channels available in my country, when i connect the cable to tv, i can watch all of them, but when to laptop i can watch only 31 of them through pinnacle pctv 340e, would you please comment on this if you have any insight into the reason of this?

It’s hard to say. There could be a variety of different reasons, including different antenna/orientation, issues with the tuner driver, buggy application software, etc. These issues tend to be extremely difficult to debug.

You may wish to make sure you are using the same antenna connection, and if possible reboot into Windows and see if you get comparable results.

Hi, I tried to apply the patch (xc4000-winfast-2.6.34.x.patch) for xc4000 module in kernel 2.6.34.7. After i have rebuilded the kernel but when i restart my system pctv 340e not work fine.
I have xc4000.fw in /lib/firmware and in in /lib/firmware/kernel_version.

Hi! Did you try the new pctv-340e_linux-2.6.35.diff file ? It is for kernel 2.6.35.x, so it may not work for you without changes, but this is currently the only patch on my web site that includes support for the PCTV 340e. The relevant parts (dib0700_devices.c and dvb-usb-ids.h) could easily be merged into the 2.6.34.x “winfast” patch, but the kernel version is possibly still an issue. In the case of errors, it would be necessary to patch these two files manually until a 2.6.34.x patch is uploaded.
There is also a complete patched V4L source package (http://corentin.ferry.free.fr/pctv-340e.tar.gz) created by Cocodidou (see above), which is basically the a79dd2ae4d0e V4L revision with my patch applied and PCTV 340e support merged.

The device showing up in lsusb is absolutely no indication as to whether a driver is available for the device. Did you install the driver mentioned in this post? You are likely to have issues applying the tree to recent kernels due to API changes by the mainline kernel developers.

The 340e and 340eSE are virtually identical from a driver standpoint. The only differences relate to the analog support (and the driver has no analog support at all), and the presence of an IR receiver.

The device can be made to work, although at this point the process is by no means optimized for regular users.